load average: 400 , task blocked for more than 120 seconds

Fórumok

sziasztok! Bocs a feltűnősködő tárgyért, de sajnos tény, hogy az egyik Debian szerverünk időnként produkálja a 3-400-as load-ot. Röviden: apache, php5 (fcgi), mysql, postfix, webszerverként üzemel + levelezés. Meghatározhatatlan gyakorisággal (2-3 hetente, naponta kétszer, stb) azt látom, hogy betelik a 8 GB memória (top szerint a nagyon sok php5 process és a mysql miatt, pedig eléggé le vissza vannak véve configban), kb 1 órán keresztül 10 és 50 között mozog a load, majd egyszer csak felmegy 2-3-400-ra, aztán leesik, utána minden rendben. Csak épp ez a folyamat kb 3 óra mire lezajlik, és a gép közben lassú illetve elérhetetlen. Érdekes módon nem fagy, nem rebootol. A swap mérete 20 GB, ezt én nem vettem volna ekkorára, de ez van, nem tudom ez okozhat-e gondot. Logokban támadás nyomait nem találtam, viszont az látszik hogy ilyenkor szinte minden processel gondja van:

kernel: [2764774.908825] INFO: task kswapd0:47 blocked for more than 120 seconds.
kernel: [2764774.908858] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[...]
kernel: [2764774.908984] INFO: task md0_raid1:292 blocked for more than 120 seconds.
[...]
kernel: [2764774.909109] INFO: task xfssyncd:320 blocked for more than 120 seconds.
[...]
kernel: [2764774.909271] INFO: task cron:1729 blocked for more than 120 seconds.
[...]

stb, szóval ilyenkor kb mindenre ezt írja, php5, mysql, postfix...

Google szerint ez a viszonylag sok memóriával és a swap-el lehet összefüggésben, tehát hogy mikor és mennyi próbál kirakni diszkre, de nem találtam rá megoldást..

Normál működés esetén van hogy hetekig elmegy 0, 1 vagy max 2-es loaddal, szóval vagy valami hirtelen terhelésről lehet szó, vagy megfut egy olyan processz ami megeszi a memóriát de még nem tudtam kideríteni hogy pontosan mi.

Konfig: sima PC, i3 CPU, 8 GB RAM, SATA diszkek szoftver raid0-ban, generic 64 bites kernel, csomagok update-elve.

Mellette üzemel egy pont ilyen szoftver felállásban üzemelő gép, de 4 GB memóriával, azzal semmi gond nincs, pedig nagyobb rajta a terheltség.

Láttatok már hasonlót? Köszi előre is!

üdv,
aboy

Hozzászólások

hasonlót láttam, ott a hálózati kártyával volt gond....
de nem merem állítani hogy itt is ez a probléma...

I/O statokat csinalj, nagy valoszinuseggel az lesz a gond.

van ilyen.

A 'blocked...120 sec' két dolgot takarhat:
- kernelhiba valmilyen alrendszerek locking tajekan (raid, sata driver, filesystem)
- tenyleg extrem lassu a diszk.

Ha a kernel lapoz, akkor amig be nem fejezi, addig nehany processz tenylegesen fogva van.
Ha a cfq vagy mas bonyolult IO utemezo van, es tobb felhasznalasu a diszk (static web: random read; mysql: rapid short fdsync; swap: rapid small writes; raid+xfs: drop barriers) Akkor elojohet a diszk IO queue vegnekuli atrendezgetese soran.

kernelhangolasi tippek:
- masik kernel (hatha szerencsed van)
- lapozasi IO meret novelese (nagyobb adagokban lapozzon):
echo 12 > /proc/sys/vm/page-cluster (ez ^12 -ot jelent, a defaul ^3 nagyon kicsi)
- a swap leszedese a mysql target diszkrol (kulon diszken legyen!)
- swap ala ne legyen raid (egy reboot az ara a diszkhalalnak)
- min free megnovelese echo_memoria_10%-a > /proc/sys/vm/min_free_kbytes
- swapiness novelese echo 100 > /proc/sys/vm/swappiness
vagy eppen lecsokkentese mondjuk 30-ra; en a 100% -ban hiszek
- dir&inode preferalasa (lapozas alol mentesitese)
echo 30 > /proc/sys/vm/vfs_cache_pressure
- CFQ helyett deadline IO utemezo. Ugyan az atlag rosszabb, de a terhelestnel kevesbe torik le.

Aztan alkalmazs-rendszergazdai dolgok:
- filesystem aktivitas helyett swap aktivitas (mert az olcsobb, mint az fs muvelet)
magyaran az atmeneti file-okat tmpfs -re mozgatni. (*)
- remote log szerver
- cron matato dolgok atgondolasa (pl mail queue muveletek nagyon megfogjak)

(*)
Egyszer mar itt a HUP-on beletort a bicskam annak az elmagyarzasaba, hogy miert is jobb, ha sokat lapoz a rendszer a sok filesystem aktivitas helyett. Ha idegen szamodra, tekints el tole.

az
echo $TIPP > /proc/sys/vm/overcommit_ratio
paranccsal eleg kicsi TIPP eseten le tudod beszelni a rendszert a swapprol. Azonban a lapozas nem ellenseg, nem mindenaron kell mgeszuntetni. Az is csak egy IO muvelet, mint a file IO. Ha meg akarod szuntetni, egyszeru swapoff a swap particiora es kesz. Es akkor adott esetben tenyleg meghal az egesz lassulas helyett...

a teljesitmenytunning ket dolgot akarhat:
- minel nagyobb atlag teljesitmenyt
- minel kisebb szorast a teljesitmenyben (megakadasok ellen)

te most kisebb szorast akarsz. Ez gyakran az atlagos teljesitmeny rontasaval erheto el. Ne add fel.

per pillanat például ilyenből van vagy 15 sor:
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
12332 mysql 20 0 1261M 1025M 5348 S 5.0 12.9 31:06.32 /usr/sbin/mysqld --basedir=/usr...

kernel: Linux 2.6.32-5-amd64 #1 SMP Thu Mar 22 17:26:33 UTC 2012 x86_64 GNU/Linux

swap gyakorlatilag üres (38/22833 MB)

közben kipróbáltam valamit: kicsomagoltam egy 15ezer kis fájlból álló gzip fájlt, mire végzett, az addigi 3 GB felhasznált memória megduplázódott és nem is csökken le, tehát már 6/8GB foglalt. Azért csináltam ezt a próbát mert eszembe jutott, mintha a legutóbbi magas load-nál is futtattam volna egy ilyen kitömörítést. A külső (web irányából) jövő terhelés a gépen továbbra sem jelentős, szerintem max 20-30 request/perc lehet...

Olvasd át amit linkeltem, nekem a memória fogyott el, pedig nem kellett volna neki. Ami a diagnosztizáláshoz kell:

vmstat vagy sar (az utóbbi kényelmesebb lehet), cat /proc/buddyinfo , ez utóbbi olyankor, amikor halódik a gép.

Esetleg foglalj le előre mondjuk 100M egybefüggő területet (http://www.mjmwired.net/kernel/Documentation/vm/hugetlbpage.txt) és pusztuláskor engedd el. Ha ez segít rajta, akkor memória fragmentáció a nyomor -> újabb kernel.

Előrebocsátom, hogy általában sem ismerem a mysql lelkét, nem hogy a deadlock-megoldásait.

De, ha a két szervered közül ugyan ezen kisebb a terhelés, viszont az adatbázisodat itt firkálják gyakrabban, akkor a konkurrenciából előálló deadlock során előbb kevesek várnak kevesekre, aztán egyre többen egyre többekre, ami letérdelésig folytatódik, vagy egyes processzek áldásos haláláig.

volt ilyenem, amiota a mysql tmp-t ramdiskre tettem, azota nincs.

Csökkentsd le a swap méretét.
Egy webszervernál már rég rossz, ha swappel.

Prefork Apache esetán a MaxRequestPerChild értékét állítsd be 1-2000 re. (Vagy a jelenleginél kisebbre.)
Php fpm esetén a child processek élettartamát állítsd be 1-2k kérés körülre.(Vagy a jelenleginél kisebbre.)
Ha memleak van valahol, akkor simán lehet, hogy hirtelen felzabálja a memóriát, elkezd vadul page-elni, majd swappelni, és kb. az van amit tapasztalsz.

Ha van valami statisztikád, hogy egyszerre átlagosan hány apache session-od van, akkor az max processes/worker értékeket ennek megfelelően maximalizáld. (Több klienst is ki tud szolgálni egy apache, mint amennyi a max, legfeljebb a felesleg vár kicsit.)

köszönöm mindenkinek a segítséget!