Dotaz: Mysql CPU 99.9%

[Michal]

Ahoj, mam problem s Mysql, pri nejakym slozitejsim dotazu, vylite vytizeni CPU na 99.9% a dotaz trva i nekolik desitek minut. Zajimave je ze to zacalo zlobit najednou az vcera, pritom to skoro pul roku fungovalo v pohode. Tak jsem zkousel upgradovat i mysql na verzi 5.0.27, ale stale nic, konfiguracni soubor my.cnf pouzivam defaultni mysql-huge.cnf. Nesetkal jste se nekdo s podobnym problemem? Dekuji.

Odpovědi

[linux.tester]

jo setkal, me to dela kdyz vypraznuje tmp tabulky z nedostaku pameti, takze bych to videl na pamet

[AraxoN]

Pravdepodobne bude chyba v tom zložitejšom dotaze. Treba ho nájsť a optimalizovať (teda ten dotaz, alebo indexy). Narazil som kedysi na to isté - keď bolo v databáze len pár desiatok riadkov, tak bolo všetko OK. Potom ale začali pribúdať a pribúdať, a čas začal narastať exponenciálne. Takže napr. pri 1000 záznamoch to bola sekunda, pri 1001 už 2 sekundy, pri 1002 4 sekundy, a za chvíľu to bolo celé nepoužiteľné. Na vine bol jeden prekomplikovaný dotaz, ktorý stačilo rozdeliť na 2.

Ak neviete, ktorý je ten zložitejší dotaz, tak mysql sa dá nastaviť tak, aby viedol log pomalých dotazov - manuál.

[Michal]

V prvni rade bych moc rad podekoval za reakce. Indexy jsem zkousel vytvorit a ten dotaz je nasledujici

 SELECT a.threadid,a.title,a.postuserid,a.postusername,b.postid,c.title,d.posts 
FROM thread a,post b,forum c,user d WHERE a.threadid=b.threadid and 
b.postid in (select max(e.postid) from post e where e.threadid=a.threadid
c.forumid and d.userid=a.postuserid and a.visible=1 and a.open=1 and 
a.forumid not in (25429) ORDER BY b.postid DESC LIMIT 10;

A pamet se zda byt v pohode

             total       used       free     shared    buffers     cached
Mem:       4149288    1557124    2592164          0      88412    1323128
-/+ buffers/cache:     145584    4003704
Swap:       524280          0     524280

[AraxoN]

jj, ten môj dotaz vyzeral navlas podobne - bolo to pre výpis diskusných tém, pričom sa k tomu naraz SELECToval aj celkový počet príspevkov v téme, a počet príspevkov, ktoré ešte daný užívateľ nevidel. Tiež som tam skúšal doplniť rôznorodé indexy, DESCRIBE SELECT nenaznačoval žiaden zádrhel, ale SELECT išiel s každým ďalším postnutým príspevkom pomalšie a pomalšie. Takže som nakoniec spravil SELECT na všetky témy, a potom pri výpise pre každú zvlášť zisťoval počty príspevkov ďalšími SELECTami. A to ku podivu ide svižne, napriek tomu, že to robí vlastne úplne presne to čo pôvodný veľký SELECT, akurát nie naraz ale postupne.

Možno je niekde v MySQL bug, pretože rovnaký dotaz nad rovnakými dátami mi vtedy Postgres zbehol bez zadýchania. Nemal som vtedy ale čas to skúmať, a pôvodnú verziu svojho pomalého SQL dotazu som už nikde nenašiel.

Btw: niekde v tom dotaze Vám chýba jedna zátvorka, takže neviem povedať či je inak správny.

[*]

a zamky si mysql bere kdy? da se to u ni nastavit? jestli pred transakci nebo az uvnitr podle potreby?