[Viilutaja]

Selline mure, et kindlal kellaajal iga päev läheb CPU kasutus kriitiliseks ja saan veateateid oma meilile.
CPU ALERT: viimased 20min on CPU kasutus yle 80% !!!
Ja täpselt 10 min pärast:
CPU OK (20min kasutus alla 90%)

Hetkel selles masinas atop käsuga avaneb selline vaatepilt. Kunagi vaatasin täpselt sellel hetkel topi, kui sain teate et CPU critical, siis näitas et 1 prose tuum jooksis 100% peal, kuid ülejäänud 3 olid kas idles või kuskil 20% juures? Tavaliselt juhtub siis ka see, et mingi kindla veebi baas kukub maha mingiks hetkeks. Mis on kummaline, sest teised mysql baasid töötavad ilusti ja veebileht saab ühendust.






Ja htop'ga näitab nii

[Fukiku]

Screenshottidelt paistab ka, et üks mysqld on see protsess, mis seda koormust tekitab. Mina uuriks siit hetkel edasi, et kas see on alati sama baas, mis pikali kukub? Kui jah, siis tuleks ilmselt uurida, et kas selles baasis või selle baasi pihta ei jookse mingeid väga koormavaid perioodilisi protsesse. Need tuleks siis ilmselt kriitilise pilguga üle vaadata, et nad masinat ei tapaks enam.

[kaabakas]

Mitte et ma mäletaks mis protsessi poolt täpselt, aga Igapäevane mysqldump viskas 100% peale küll.

[eldorado]

taskset -c 2-3 chrt -f 1 <command>

kus 2-3 on processori #

määrad lihtsalt manualli kahe protsessori peale seda protsessi ja ongi korras. näit nendele mis on vähem koormatud.
Tegelikult natukene otsimisel võib leida kuidas ainult üks task jääta CPU kohta

[Fukiku]

Alustada võiks siiski sellest, et identifitseerida täpselt protsess ja põhjused, et miks load üles viskab. Kui on selge, et seda kuidagi elimineerida ei saa, siis vast tasub järgmiste meetodite peale mõtlema hakata.

[eldorado]

[kaabakas]

Kui ainult üks core on 100%, ja eelnevalt pole piiratud corede arvu protsessile (by default ei tohiks olla), siis minu aru järgi peab süüdlaseks olema üksainus thread mysql sees. Mitu threadi jagaks kernel sujuvalt mitme core peale laiali, aga ühtainust kuidagi pooleks ei tee. Sel juhul pole ka abi tasksel'ist, millega saab sel juhul defaulte ainult piirata, aga mitte avardada. Juhul, kui corede arvu on siiski piiratud, aitab tasksel piirangut tõsta, kuid kõigepealt oleks siis tarvis teada, kes ja miks on piirangu kehtestanud. Lisaks ei saa mööda vajadusest välja uurida, mis selle koormuse siiski tekitab.

Eeldatavasti tähendab see thread(?) ühte klienti kes teeb üsna suure päringu. Eriti veel kui see toimub kindlal kellaajal, seega igatahes mingi automaatika läbi. Kas teemaalgataja on juba kindlaks teinud, et see pole labane mysqldump otse crontabist? Backuppimiseks on paremaid lahendusi ka kui keset päeva dumpi teha. Peenema detektiivi tegemiseks näitab nii phpmyadmin kui loomulikult mysql ise statistikat ja muud kavalat.

Minu kogemuses vist ainult log replay suudab lisaks suurele päringule pikalt koormust tekitada, kuid seda esineb ainult katki kukkunud baasi taaskäivitamisel. Vbl on abi mõttele abi ka sellest: http://dev.mysql.com/doc/refman/5.6/en/mysql-threads.html