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
- 3416 megtekintés
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...
- A hozzászóláshoz be kell jelentkezni
I/O statokat csinalj, nagy valoszinuseggel az lesz a gond.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
egeresz: köszi!
echo 2 > /proc/sys/vm/overcommit_memory
és
echo 80 > /proc/sys/vm/overcommit_ratio
-val próbálkoztam eddig, de úgy tűnik eredménytelenül. Végigpróbálgatom a tippeket!
üdv,
aboy
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"- CFQ helyett deadline IO utemezo. Ugyan az atlag rosszabb, de a terhelestnel kevesbe torik le."
ezt probaltam anno, nem jott be. talaltam valami rh fejleszto altal javitott kernelt is, ami pont egy ilyen tuneteket okozo hibat szuntet meg, de nem jott be az sem.
- A hozzászóláshoz be kell jelentkezni
A mysql mennyi memóriát eszik? Melyik kernel? A swap-od hogy áll?
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
köszi, végignézem!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
volt ilyenem, amiota a mysql tmp-t ramdiskre tettem, azota nincs.
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
köszönöm mindenkinek a segítséget!
- A hozzászóláshoz be kell jelentkezni