VPS-en elfogy a memória

Debian GNU/Linux

Sziasztok,

Van egy Xen PV(?) VPS-em 1GB memóriával + 1 CPU maggal és Debian 6 rendszerrel, amelyen bizonyos időközönként (kb. 4 havonta) elfogy a memória. Nos ez azért érdekes, mert korábban ugyanaz a weblap 512mb memóriával vígan elfutott és azóta a látogatottság ~30%-kal csökkent, tehát a memóriának bőven elégnek kellene lennie, emellett az egész az egyik pillanatról a másikra történik, nem látok semmilyen "jelet" arra, hogy ez be fog következni. Mivel a memória megtelik, ezért loginolni nem tudok sem ssh-n, sem konzolon keresztül. Most letiltottam az overcommit-ot az echo 2 > /proc/sys/vm/overcommit_memory (0-án volt) paranccsal és egyelőre kevesebb memóriát eszik, de nem tudom, hogy ez megoldja a problémámat.

Csatolom a munin néhány grafikonját, hátha ti többet láttok rajta :)

Kérdés1: mi okozhatja a problémát és hogy lehetne elhárítani?
Kérdés2: hogy lehetne megoldani, hogy ha bármi is történik, mindig be tudjak lépni legalább konzolon keresztül?

A képet a Képfeltöltés.hu tárolja.

A képet a Képfeltöltés.hu tárolja.

A képet a Képfeltöltés.hu tárolja.

  • 3541 megtekintés

( andrej_ v | 2011. 11. 29., k – 10:58 )

Azt nézd meg elkezd-e swappelni ebben az időben. Az apache vagy más memóra éhes dolog elég hirtelen el tud szállni. Érdemes a webszerver access logokat is megnézni, hogy nincs-e valami hirtelen roham.

A PHP és Apache (vagy hasonló) ugye rendesen frissített?

Néha ránézek (kb. havonta), hogy van-e frissítés, olyankor frissítek. Most néztem és nem volt semmi új Apache-hoz és PHP-hoz sem.

SWAP-on megint nem látszik semmi:
kép

Access logot átnézve a 173.237.187.248 IP címről másodpercenként ~10-20 HEAD/GET lekérdezés érkezett kb fél percig Opera/Presto user agenttel, de ezenkívül semmi különös.

Hmmm, syslogban első hibaüzenet, hogy a postfix nem tud csatlakozni a mysql-hez, majd 8 percre rá jönnek az oom-killer üzenetek.

Apache prefork config:

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 5
MaxClients 150
MaxRequestsPerChild 500
</IfModule>

Szerk: a 150-es MaxClients-et levettem 15-re, mert nincs túl sok konkurens kérés.

Syslog:

Nov 28 23:54:28 mandarin kernel: [10212544.309771] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Nov 28 23:54:48 mandarin kernel: [10212544.309777] mysqld cpuset=/ mems_allowed=0
Nov 28 23:54:48 mandarin kernel: [10212544.309780] Pid: 4477, comm: mysqld Not tainted 2.6.32-5-amd64 #1
Nov 28 23:54:48 mandarin kernel: [10212544.309782] Call Trace:
Nov 28 23:54:48 mandarin kernel: [10212544.309792] [] ? oom_kill_process+0x7f/0x23f
Nov 28 23:54:48 mandarin kernel: [10212544.309795] [] ? __out_of_memory+0x12a/0x141
Nov 28 23:54:48 mandarin kernel: [10212544.309797] [] ? out_of_memory+0x140/0x172
Nov 28 23:54:48 mandarin kernel: [10212544.309801] [] ? __alloc_pages_nodemask+0x4e5/0x5f4
Nov 28 23:54:48 mandarin kernel: [10212544.309804] [] ? __do_page_cache_readahead+0x9b/0x1b4
Nov 28 23:54:48 mandarin kernel: [10212544.309807] [] ? ra_submit+0x1c/0x20
Nov 28 23:54:48 mandarin kernel: [10212544.309811] [] ? filemap_fault+0x17d/0x2f6
Nov 28 23:54:48 mandarin kernel: [10212544.309816] [] ? __do_fault+0x54/0x3c3
Nov 28 23:54:48 mandarin kernel: [10212544.309820] [] ? do_sync_write+0xce/0x113
Nov 28 23:54:48 mandarin kernel: [10212544.309823] [] ? handle_mm_fault+0x3b8/0x80f
Nov 28 23:54:48 mandarin kernel: [10212544.309829] [] ? xen_hvm_callback_vector+0xe/0x18
Nov 28 23:54:48 mandarin kernel: [10212544.309835] [] ? do_page_fault+0x2e0/0x2fc
Nov 28 23:54:48 mandarin kernel: [10212544.309838] [] ? page_fault+0x25/0x30
Nov 28 23:54:48 mandarin kernel: [10212544.309840] Mem-Info:
Nov 28 23:54:48 mandarin kernel: [10212544.309841] Node 0 DMA per-cpu:
Nov 28 23:54:48 mandarin kernel: [10212544.309843] CPU 0: hi: 0, btch: 1 usd: 0
Nov 28 23:54:48 mandarin kernel: [10212544.309845] Node 0 DMA32 per-cpu:
Nov 28 23:54:48 mandarin kernel: [10212544.309847] CPU 0: hi: 186, btch: 31 usd: 30
Nov 28 23:54:48 mandarin kernel: [10212544.309851] active_anon:101279 inactive_anon:101349 isolated_anon:902
Nov 28 23:54:50 mandarin kernel: [10212544.309852] active_file:130 inactive_file:884 isolated_file:26
Nov 28 23:54:50 mandarin kernel: [10212544.309853] unevictable:0 dirty:0 writeback:163 unstable:0
Nov 28 23:54:50 mandarin kernel: [10212544.309854] free:1993 slab_reclaimable:2942 slab_unreclaimable:7541
Nov 28 23:54:50 mandarin kernel: [10212544.309855] mapped:862 shmem:1538 pagetables:31078 bounce:0
Nov 28 23:54:50 mandarin kernel: [10212544.309857] Node 0 DMA free:4012kB min:60kB low:72kB high:88kB active_anon:5100kB inactive_anon:5296kB active_file:0kB inactive_file:160kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15364kB mlocked:0kB dirty:0kB writeback:0kB mapped:28kB shmem:92kB slab_reclaimable:136kB slab_unreclaimable:268kB kernel_stack:176kB pagetables:480kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:54 all_unreclaimable? yes
Nov 28 23:54:50 mandarin kernel: [10212544.309866] lowmem_reserve[]: 0 990 990 990
Nov 28 23:54:50 mandarin kernel: [10212544.309868] Node 0 DMA32 free:3960kB min:3992kB low:4988kB high:5988kB active_anon:400016kB inactive_anon:400100kB active_file:520kB inactive_file:3376kB unevictable:0kB isolated(anon):3608kB isolated(file):104kB present:1014040kB mlocked:0kB dirty:0kB writeback:652kB mapped:3420kB shmem:6060kB slab_reclaimable:11632kB slab_unreclaimable:29896kB kernel_stack:4288kB pagetables:123832kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8054 all_unreclaimable? yes
Nov 28 23:54:50 mandarin kernel: [10212544.309877] lowmem_reserve[]: 0 0 0 0
Nov 28 23:54:50 mandarin kernel: [10212544.309880] Node 0 DMA: 3*4kB 4*8kB 50*16kB 9*32kB 9*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 4012kB
Nov 28 23:54:50 mandarin kernel: [10212544.309886] Node 0 DMA32: 774*4kB 22*8kB 3*16kB 0*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Nov 28 23:54:50 mandarin kernel: [10212544.309892] 20712 total pagecache pages
Nov 28 23:54:50 mandarin kernel: [10212544.309894] 18148 pages in swap cache
Nov 28 23:54:50 mandarin kernel: [10212544.309895] Swap cache stats: add 4971315, delete 4953167, find 2155781459/2156794312
Nov 28 23:54:50 mandarin kernel: [10212544.309897] Free swap = 0kB
Nov 28 23:54:50 mandarin kernel: [10212544.309898] Total swap = 1951736kB
Nov 28 23:54:50 mandarin kernel: [10212544.313331] 261120 pages RAM
Nov 28 23:54:50 mandarin kernel: [10212544.313333] 5314 pages reserved
Nov 28 23:54:50 mandarin kernel: [10212544.313334] 87279 pages shared
Nov 28 23:54:50 mandarin kernel: [10212544.313335] 248961 pages non-shared
Nov 28 23:54:50 mandarin kernel: [10212544.313339] Out of memory: kill process 4321 (apache2) score 104915 or a child
Nov 28 23:54:50 mandarin kernel: [10212544.314191] Killed process 4321 (apache2)

A MySQL nem jelez lassú lekérdezéseket. Ezenfelül nem tudom, de nem hiszem, mert másodpercenként kb ~20 lekérdezés történik, ami azért nem nevezhető soknak :)

Augusztusban módosítottam a kódon, azért van ez a nagy ugrás benne:
kép

kép

Szerk: mi a különbség a Queries in cache és a Cache hits között?
kép

Access logot átnézve a 173.237.187.248 IP címről másodpercenként ~10-20 HEAD/GET lekérdezés érkezett kb fél percig Opera/Presto user agenttel, de ezenkívül semmi különös.

Csak amit előbb említettem. Valószínűleg akkor történhetett valami, mert rögtön azután jött az első MySQL-es probléma.

Ha Xen akkor nem tudnak overcommittolni memóriát, legalábbis legutóbb még ez volt a helyzet. Azt nézd meg, hogy 32 vagy 64 bites a mostani rendszer és hogy az előző milyen volt. 64 biten ugyanis több memóriát esznek az appok.

Tényleg olyasmi jöhet képbe, a szolgáltatói oldalt nézve, hogy a hoszt gépen szűkös az IO (akár csak időnként) vagy valamiért nincs a Hypervisor a helyzet magaslatán.

Az más, az a guestként Linux memória kezelése, nincs köze a hosthoz.

http://www.mjmwired.net/kernel/Documentation/filesystems/proc.txt szerint:

"Committed_AS: The amount of memory presently allocated on the system. The committed memory is a sum of all of the memory which has been allocated by processes, even if it has not been"used" by them as of yet. A process which malloc()'s 1G of memory, but only touches 300M of it will only show up as using 300M of memory even if it has the address space allocated for the entire 1G. This 1G is memory which has been "committed" to by the VM and can be used at any time by the allocating application. With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'), allocations which would exceed the CommitLimit (detailed above) will not be permitted. This is useful if one needs to guarantee that processes will not fail due to lack of memory once that memory has been successfully allocated."

Tehát szépen megy túljegyzés OS-en belül is. :)

Egy crawlerrel kigyűjtöttem ~600 url-t, majd ezzel a megoldással 50 konkurens kéréssel elkezdtem "bombázni" a gépet. Érdekes, hogy az 50-es paraméter ellenére ~20 tényleges kérés érkezett másodpercenként az accesslog tanulsága szerint.

Eredmény:
1. A weboldalon futó fórum motor (Invision Power Board) visszadobál HTTP 500-zal mindent, mondván túl nagy a terhelés.
2. Load felszökött 14-re
3. Memória-használat felment 600mb-ra
4. CPU kihasználtság 100%
5. ennyi :)

Ha valaki tud automata crawler + stress tester eszközt, vagy az előbbinél jobb megoldást, az szóljon :]

( Proci85 v | 2011. 11. 29., k – 12:39 )

A munin egy kicsit érzékeny a terhelésekre. Amint valami komolyabb terhelés éri a rendszert, ő köszöni szépen, timeout -tal inkább befejezi munkáját, a grafikonjaid meg szép üresek lesznek.
Javaslom MRTG-t is használj. Drúva nagy loadnál is rajzolja a grafikonokat amiből sok okosság kiderül.

Csak, hogy néhányat említsek: 


#----------------------------
# Network
#----------------------------
Target[eth0]: `cat /proc/net/dev | grep eth0 | cut -d":" -f 2 | awk '{print$1;print$9}'`
Title[eth0]: Traffic on eth0
PageTop[eth0]: <h1>Traffic on eth0</h1>
Options[eth0]: growright,nobanner,nolegend,noinfo,nopercent
YLegend[eth0]: Byte/s
MaxBytes[eth0]: 500000000
AbsMax[eth0]: 500000000000
Shortlegend[eth0]: Byte/s
LegendI[eth0]: IN:
LegendO[eth0]: OUT:
#Unscaled[eth0]: d

#----------------------------
# TCP Connections
#----------------------------
Target[tcp]: `netstat -an | grep -c ESTABLISHED; echo 0`
Title[tcp]: Established TCP Connections
PageTop[tcp]: <H1>Established TCP Connections</H1>
YLegend[tcp]: Connections
ShortLegend[tcp]: Connect
#LegendI[tcp]: Connect
#LegendO[tcp]: Connect
MaxBytes[tcp]: 50000

#----------------------------
# Sysload
#----------------------------
Target[sysload]: `uptime | sed -e 's/^.*average.*: \(.*\)$/\1/' -e 's/ //g' | awk -F, '{ printf("%.0f\n",$2); printf("%.0f\n",$3) }'; uptime | sed 's:^.* up \(.*\), [0-9][0-9]* users.*$:\1:'; uname -n`
Title[sysload]: System load
PageTop[sysload]: <h1>System load</h1>
MaxBytes[sysload]: 3000
Options[sysload]: growright,gauge,nopercent,nobanner,nolegend
YLegend[sysload]: Load 
ShortLegend[sysload]: 
LegendI[sysload]: Load:
LegendO[sysload]: 15 min.avg:


#----------------------------
# Memory
#----------------------------
Target[memory]: `free -b |grep cache:|cut -d ":" -f2|cut -c1-11; free -b |grep cache:|cut -d ":" -f2|cut -c12-22`
Title[memory]: Free Memory
PageTop[memory]:<h1> Free Memory</h1>
YLegend[memory]: Byte
Shortlegend[memory]: Byte
MaxBytes[memory]: 2048000000
Kilo[memory]:1024
LegendI[memory]: Used RAM
LegendO[memory]: Free RAM
Unscaled[memory]:d

#--------------------------


#----------------------------
# All-Processes
#----------------------------
Target[processes]: `cut -d ' ' -f4 /proc/loadavg | cut -d '/' -f 1; cut -d ' ' -f4 /proc/loadavg | cut -d '/' -f 2`
Title[processes]: Processes
PageTop[processes]: <H1>Processes</H1>
YLegend[processes]: Processes
Shortlegend[processes]: Process
LegendI[processes]: Running:
LegendO[processes]: Total:

#----------------------------
# Apache-Processes
#----------------------------
Target[apache]: `ps aux| grep -c /usr/sbin/apache; ps aux| grep -c  /usr/sbin/mysqld`
Title[apache]: Apache-Processes
PageTop[apache]: <H1>Apache-Processes</H1>
YLegend[apache]: Processes
Shortlegend[apache]: Process
LegendI[apache]: Apache:
LegendO[apache]: MySQL:

Fincsinek néz ki, de ma csináltam aptitude-dal frissítést, amivel jött le egy kernel image.
Log:
[UPGRADE] linux-image-2.6.32-5-amd64 2.6.32-38 -> 2.6.32-39


root@mandarin:/var/log# uname -a
Linux mandarin 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 GNU/Linux

Az eddig lemaradt, hogy régebben másik szolgáltatónál futott 512mb memóriával, ugyancsak Xen rendszeren. Amióta átjöttem, azóta ez már a ~3-4. ilyen problémám.

( hccoder | 2011. 11. 29., k – 13:53 )

Ez engem is érdekel.
Ugyanígy Debian 6-on 1 maggal(2Ghz) + 1Gb RAM-al. Nálam kb. 10 weboldal fut róla + levelezés. Megtörtént legutoljára 30 napja, előtte kb 60 nappal volt ugyanilyen leállás, a szolgáltató control paneljéről tudtam csak újraindítani a gépet. Mivel csak játszós serverről van szó nem volt kedvem alaposabban utánajárni, hogy mi történhetett. Logokat átlapoztam de semmi nem volt bennük, muninban ugyanilyen szakadás volt.

( mallee | 2011. 12. 19., h – 15:22 )

Kaptam tegnap este egy nagyobb löketet, valami robot keresett "rossz" szkripteket az oldalon, de elég hevesen tette:
Apache
Load
CPU

A jó hír az, hogy nem halt meg tőle a gép, sőt a memória-kihasználtságon sem látszik túl sok minden:
Memory

( mallee | 2012. 04. 04., sze – 10:52 )

Az elmúlt közel fél évben a probléma nem jelentkezett, valószínűleg valamilyen frissítés vagy a fenti beállítások egyike, kombinációja megoldotta a problémát. :)

De az is lehet, hogy a szolgáltató csinált valamit.

Időnként nekem is előtör a semmiből egy-egy ilyen hiba. Xen, 64 bites debian rendszer, apachet futtató vhost. Nekem az overcommit tiltása és az apache finomhangolása (esetleg még az updatek) segített valamennyit, de időnként még mindig vannak "cannot fork..." hibák és szeretnék megszabadulni tőlük. Bármi ötlet van még, azt szívesen veszem :)

--
TH