|
Query koji optereti server ?
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 |
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...
|
Citat:
|
Mysql ima tzv slow query log - da bi ga omogućio dodaj ovaj kod u konfiguraraciju servera:
Kôd:
log-slow-queries = /var/log/mysql/mysql-slow.log |
Ne zaboravi da ukljucis i bacis pogled na "slow queries" log u MySQL-u.
http://dev.mysql.com/doc/refman/5.0/...query-log.html |
kad ustanovis koji je to query, daj molim te postuj ga ovde, bas me zanima.
|
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. |
Citat:
|
Ja tipujem na bar jedno od sledećih 4:
1. Podaci se ne nalaze u 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. |
Ne lici mi na mysql problem..
Pocelo kladjenje :) |
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...
|
Ili da jednostavno promenis admin-a ? :)
|
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. |
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... |
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? |
Ne, ne, ne decko, tako se ne prave avioni... Ne greshish uopshte...
|
Blues, jesi li otkrio šta je u pitanju?
|
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. 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 |
evo jedan dobar clanak o kontroli resursa koje trosi mysql:
http://www.oreillynet.com/databases/..._a_mysq_1.html |
"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...
|
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. |
Znas koliko mi je pucala štikla za "specifikacije i modelovanje softvera" dok sam krmeljiv trazio sta mi modeluje živce 2 dana? :D
|
| Vreme je GMT +2. Trenutno vreme je 10:34. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.