PDA

Pogčedajte punu verziju : Query koji optereti server ?


bluesman
13. 02. 2007., 19:13
Primetili ste da se poslednjih dana server "ružno" ponaša, dešava se po 2-3 puta dnevno da je nodostupan. Nije pao, već mu je load veliki pa ne prolaze http zahtevi, i posle dugog učitavanja dobije se "not found".

Sada, ustanovili smo da je problem ili do mysqld ili httpd ili oba. Restartovanje jednog od ova dva servisa, ili ponekad oba, rešava problem, ali je to prilično glupo rešenje, ne možeš da sediš ceo dan i čekaš kad ćeš da restartuješ servise...

Elem, ustanovili smo da su problemi počeli pre par dana, baš kada smo otvorili jedan novi domen koji je osim što je prilično veliki, izgleda i loše napisan, pa smo pronašli da se neki mysql query-ji izvršavaju po 5 minuta ?!?!

Danas smo suspednovali taj nalog, ako ništa drugo bar da proverimo da li je to uzrok svih problema, i što se kaže "so far so good". Ali da se ne radujem prerano, da li neko ima drugu ideju šta može da pravi te probleme?

Takođe smo danas isključili i mogućnost permanent konekcije u mysql, da vidimo da možda i to ne utiče. MySQL je 5.0.24a a PHP je 5.0.4 sa Zend 2.0.4-dev, Zend Optimizer 2.6.2

Peca
13. 02. 2007., 19:26
Sa SQL query-jem SHOW PROCESSLIST; mozes da vidis spisak query-ja koji se tog trenutka izvrsavaju, vidi se nalog i duzina izvrsavanja, pa tako mozes da vidis koji nalog 'obara' server na kolena...

phatsa
13. 02. 2007., 19:39
pa smo pronašli da se neki mysql query-ji izvršavaju po 5 minuta ?!?!


sunce ti... query od 5 minuta... moguce da u mysql bazi nema indeksa po potrebnim poljima koja se koriste u queriju, ili primarnih kljuceva?

Petar Marić
13. 02. 2007., 19:50
Mysql ima tzv slow query log (http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html) - da bi ga omogućio dodaj ovaj kod u konfiguraraciju servera:
log-slow-queries = /var/log/mysql/mysql-slow.log
long_query_time = 10
Dodatne informacije možeš naći ovde (http://www.databasejournal.com/features/mysql/article.php/2013631).

dinke
13. 02. 2007., 19:50
Ne zaboravi da ukljucis i bacis pogled na "slow queries" log u MySQL-u.

http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html

kodi
13. 02. 2007., 19:55
kad ustanovis koji je to query, daj molim te postuj ga ovde, bas me zanima.

dinke
13. 02. 2007., 20:02
Licno sumnjam da je bas query u pitanju, jer bi query od 5 minuta podrazumevao i vrlo velike(i neindeksovane) tabele.

Moj tip je na nekoj nekompatibilnosti nekog od (apache)modula, tim pre sto je instalacija bila relativno nedavno. S tim u vezi treba dobro pogledati u apache i sistemski error log.

jablan
13. 02. 2007., 21:18
Licno sumnjam da je bas query u pitanju, jer bi query od 5 minuta podrazumevao i vrlo velike(i neindeksovane) tabele.
Nije nemoguće da je query, svakakve sam perverzije viđao u SQL-u. U nekima sam bio prinuđen i da učestvujem... ;) Ako ima velikih tekstualnih polja, blobova, string operacija itd itd, svaša može da se dešava.

Petar Marić
13. 02. 2007., 21:39
Ja tipujem na bar jedno od sledećih 4:
1. Podaci se ne nalaze u 3NF (http://en.wikipedia.org/wiki/3NF),
2. Povezivanje tabela podupitima ili preko dekartovog proizvoda umesto join-a,
3. Složenija operacija nad tabelom koja ne koristi indekse,
4. Varijanta za 3. - pretraga tekstualnih polja pomoću LIKE "%nešto%" umesto preko full-text pretrage.

MorenoArdohain
13. 02. 2007., 21:48
Ne lici mi na mysql problem..

Pocelo kladjenje :)

bluesman
13. 02. 2007., 22:20
Iskreno i meni je malo verovatno da je mysql (zato sam i stavio znak pitanja u naslovu teme), kakav god da je query, ne bi trebalo da toliko utice. Ja pre tipujem na ovo sto dinke kaze (apache) ili na neki "memory limit" setting u .conf...

nixa
13. 02. 2007., 22:52
Ili da jednostavno promenis admin-a ? :)

Petar Marić
13. 02. 2007., 23:03
Heh, imao sam prilike da vidim upit nad jednom tabelom sa oko 1.5M redova koji traje 60+ sekundi upravo zato što su ljudi kostili LIKE "%nešto%" umesto full-text pretrage. Što je još gore - dotična aplikacija se još uvek koristi :(

@Blues, izem ga - trebao bi se pojaviti u apache, mysql, system, ... logu ako je u pitanju programska greška.

Peca
14. 02. 2007., 05:21
Znate li kako jedan OR koji se slucajno nasao bez obaveznih zagrada, u upitu koji spaja dve vece tabele, moze da ubije i mysql i apache...
Samo tako :)
Jer mysql zbog neopreznog OR pocne svasta da spaja... zagarantovan prekid na nekoliko minuta... mozda i vise...

zextra
14. 02. 2007., 10:41
Ja sam uspeo malocas da blokiram mysql na 15ak sekundi sa dve left joined tabele (jedna oko 2k zapisa, druga oko 6k), pri cemu je u drugoj FK polje bilo bez indeksa, cisto probe radi :) Pitam se sta bi bilo da sam u test ubacio i LIKE ;)

Cisto da vidim jesam li dobro razumeo - ako FK polje iz tabele sa desne strane joina ne pripada indexu (a ko je jos lud da uradi tako nesto? :)), za svaki red tabele sa leve strane prolazi kroz sve redove tabele sa desne strane :) sto je u mom slucaju znacilo da je veca tabela od 6k skenirana top-to-bottom nekih 2k puta. Gresim li negde?

LiquidBrain
14. 02. 2007., 10:59
Ne, ne, ne decko, tako se ne prave avioni... Ne greshish uopshte...

Petar Marić
15. 02. 2007., 15:49
Blues, jesi li otkrio šta je u pitanju?

gastonr
15. 02. 2007., 16:16
Ja sam imao sličan problem sa očajno napisanim php kodom i funkcijom php_eregi. Kod nisam ja pisao, već sam koristio gotov skript (komponenta za joomla CMS) Wap4joomla.

Elem, problem je bio u tome što je taj Wap4Joomla navodno prečiščavao HTML kod od "nepotrebnih" kodova za formatiranje sadržaja i takav "prečišćen" kod prikazivao na Wap stranici.
E sad, kad skript naiđe na neki tag koji nije predviđen on se zakuca i digne server load u p.m. :(.
Bilo je o tome diskusije i na forum.joomla.org (http://forum.joomla.org/index.php/topic,128834.0.html).
I ja sam prvo pomislio da je neki query u pitanju, ali ispostavilo se da nije.
Hoću da kažem da je vrlo moguće da i očajno napisan php kod zakucava server.

poz,
GR

ivanhoe
15. 02. 2007., 19:09
evo jedan dobar clanak o kontroli resursa koje trosi mysql:
http://www.oreillynet.com/databases/blog/2006/07/measuring_resources_for_a_mysq_1.html

bluesman
15. 02. 2007., 22:06
"Igrali smo se" malo (u ocajanju) sa php.ini i evo vec 2 dana se nije desio problem. Sta je promenjeno? Nemam pojma :( Sve je menjano, a moguce je cak i da je na kraju zavrsio u default stanju...

Petar Marić
16. 02. 2007., 00:05
Jedna od stvari koje su nas učili na Specifikaciji i modelovanju softvera:
Kada popravljaš bug nikad ne pravi 2 izmene, inače nećeš znati koja je izmena ispravila bug.

bluesman
16. 02. 2007., 00:34
Znas koliko mi je pucala štikla za "specifikacije i modelovanje softvera" dok sam krmeljiv trazio sta mi modeluje živce 2 dana? :D