OOM-Killer tötet Dinge mit viel (?) Freiem RAM

Der OOM-Killer scheint Dinge zu töten, obwohl auf meinem System mehr als genug freier Arbeitsspeicher vorhanden ist:

Grafik zur Speicherauslastung (Komplettlösung)

27 Minuten und 408 Prozesse später reagierte das System erneut. Ich habe es ungefähr eine Stunde später neu gestartet und bald darauf hat sich die Speicherauslastung wieder normalisiert (für diesen Computer).

Bei der Inspektion laufen einige interessante Prozesse auf meiner Box:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

Dieser spezielle Server läuft seit ca. 8 Stunden, und dies sind die einzigen zwei Prozesse, die solche ... ungeraden Werte haben. Mein Verdacht ist, dass "etwas anderes" vor sich geht, das möglicherweise für diese unsinnigen Werte relevant ist. Insbesondere denke ich, dass das System denkt, dass es nicht genügend Speicher hat, obwohl dies in Wirklichkeit nicht der Fall ist. Immerhin glaubt es, dass rsyslogd konsistent 55383984% CPU verwendet, wenn das theoretische Maximum auf diesem System ohnehin 400% beträgt.

Dies ist eine vollständig aktuelle CentOS 6-Installation (6.2) mit 768 MB RAM. Anregungen, wie Sie herausfinden können, warum dies geschieht, sind willkommen!

bearbeiten: vm anhängen. sysctl tunables .. Ich habe mit Swappiness gespielt (was durch 100 deutlich wird), und ich führe auch ein absolut schreckliches Skript aus, das meine Puffer und meinen Cache ablegt (was durch vm.drop_caches mit 3 deutlich wird) + synchronisiert die Festplatte alle 15 Minuten. Aus diesem Grund wuchsen die zwischengespeicherten Daten nach dem Neustart auf eine etwas normale Größe, fielen dann aber schnell wieder ab. Ich erkenne, dass Cache eine sehr gute Sache ist, aber bis ich das herausgefunden habe ...

Interessant ist auch, dass meine Auslagerungsdatei während des Ereignisses zwar gewachsen ist, aber nur ~ 20% der insgesamt möglichen Auslastung erreicht hat, was für echte OOM-Ereignisse nicht charakteristisch ist. Am anderen Ende des Spektrums wurde die Festplatte im selben Zeitraum absolut verrückt, was für ein OOM-Ereignis charakteristisch ist, wenn die Auslagerungsdatei abgespielt wird.

sysctl -a 2>/dev/null | grep '^vm'::

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

edit: und die erste OOM-Nachricht anhängen ... bei näherer Betrachtung heißt es, dass etwas eindeutig aus dem Weg gegangen ist, um auch meinen gesamten Swap-Bereich zu verschlingen.

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

— Kyle Brantley
quelle

Können Sie die Ausgabe von bereitstellen sysctl -a 2>/dev/null | grep '^vm'?

— Patrick

Hinzugefügt. Hoffentlich können Sie (oder jemand) etwas finden, das ich verpasst habe.

— Kyle Brantley

Das einzige, was mir auffällt, ist die overcommit_memoryEinstellung. Das Setzen auf 1 sollte dieses Verhalten nicht verursachen, aber ich hatte noch nie das Bedürfnis, es auf "immer überbeansprucht" zu setzen, also nicht viel Erfahrung dort. Bei den anderen von Ihnen hinzugefügten Notizen haben Sie festgestellt, dass der Swap nur zu 20% verwendet wurde. Laut OOM-Protokollspeicherauszug Free swap = 0kB. Es wurde definitiv angenommen, dass der Tausch zu 100% genutzt wurde.

— Patrick

Antworten:

Ich habe mir gerade den oom log dump angesehen und die Genauigkeit dieses Diagramms in Frage gestellt. Beachten Sie die erste Zeile 'Node 0 DMA32'. Er sagt free:3376kB, min:3448kBund low:4308kB. Immer wenn der freie Wert unter den niedrigen Wert fällt, soll kswapd anfangen, Dinge auszutauschen, bis dieser Wert wieder über den hohen Wert steigt. Immer wenn free unter min fällt, friert das System grundsätzlich ein, bis der Kernel es wieder über den min-Wert bringt. Diese Meldung zeigt auch an, dass der Swap vollständig dort verwendet wurde, wo er steht Free swap = 0kB.
Im Grunde genommen wurde kswapd ausgelöst, aber der Swap war voll, sodass nichts möglich war, und der Wert für pages_free lag immer noch unter dem Wert für pages_min. Die einzige Option bestand darin, Dinge zu beenden, bis pages_free wieder gesichert werden konnte.
Sie haben definitiv keinen Speicher mehr.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html bietet eine wirklich gute Erklärung, wie das funktioniert. Siehe den Abschnitt 'Implementierung' unten.

— Patrick
quelle

Dann braucht das OP wirklich einfach mehr RAM ...

— ewwhite

mehr Widder oder herausfinden, was es isst.

— Patrick

Ich habe die Linien sehr genau in diese Grafik eingefügt. Die Protokolldaten wurden ~ 1-2 m vor dem Abbruch des ersten Prozesses gestoppt und die Protokolldaten ~ 4-5 m nach dem Abbruch des letzten Prozesses fortgesetzt. An diesem Punkt wette ich, dass ein Prozess völlig durcheinander geraten ist und angefangen hat, meine Auslagerungsdatei zu verprügeln - sobald er endlich alles hat, hat er auch die Prozesse beendet, die funktionell aus der Auslagerungsdatei herausgelaufen sind, weshalb, als die Daten zurückgegeben wurden, Die Auslagerungsdatei war erhöht, aber nicht voll. Vorschläge, wie Sie feststellen können, was dies tut, sind willkommen!

— Kyle Brantley

@KyleBrantley Welche Werte ziehen Sie, um das Diagramm zu generieren? Einer der Nachteile des virtuellen Linux-Speichersystems ist, dass es keine konkrete Definition von "frei" gibt. Es gibt ein Dutzend Möglichkeiten, "freien Speicher" zu definieren. Was kswapd betrifft, ist der Wert pages_free von Bedeutung. Was den kostenlosen Tausch betrifft, weiß ich nicht, welchen Wert Sie lesen könnten, der so weit entfernt wäre. Die einzige Möglichkeit, wirklich zu sehen, was den Speicher verschlingt, besteht darin, fortlaufende Schnappschüsse aller Prozesse auf der Box zu protokollieren und zu sehen, was den gesamten Speicher verbraucht, wenn der Oom-Killer verrückt wird.

— Patrick

Ja, mir ist der Speicher ausgegangen. Ich durchsuchte die Protokolle und stellte fest, dass meine untergeordneten Apache-Prozesse wiederholt abgebrochen wurden, was mich zu der Feststellung führte, dass ich funktionell unendliche untergeordnete Prozesse hatte, die gestartet werden konnten . Alles, was es brauchte, waren die automatisierten Blogspam-Bots, die dem Host eine Menge Anfragen pro Sekunde zuwarfen, damit er umfiel. Das Optimieren von Apache löste alles.

— Kyle Brantley

Entfernen Sie das drop_caches-Skript. Darüber hinaus sollten Sie die relevanten Teile Ihrer dmesgund der /var/log/messagesAusgabe mit den OOM-Nachrichten veröffentlichen.

Um dieses Verhalten zu stoppen, würde ich empfehlen, dieses sysctlTunable zu versuchen . Dies ist ein RHEL / CentOS 6-System, das eindeutig auf eingeschränkten Ressourcen ausgeführt wird. Ist es eine virtuelle Maschine?

Versuchen Sie zu ändern, /proc/sys/vm/nr_hugepagesund prüfen Sie, ob die Probleme weiterhin bestehen. Dies könnte ein Problem mit der Speicherfragmentierung sein, prüfen Sie jedoch, ob diese Einstellung einen Unterschied macht. Um die Änderung dauerhaft zu machen, fügen vm.nr_hugepages = valueSie sie hinzu /etc/sysctl.confund führen Sie sie aus, sysctl -pum die Konfigurationsdatei erneut zu lesen ...

Siehe auch: Interpretieren der Meldungen "Seitenzuordnungsfehler" des kryptischen Kernels

— ewwhite
quelle

Die erste Oom-Killer-Nachricht wurde hinzugefügt. Während MySQL die RAM-intensivste Sache ist, die ich verwende, habe ich es so eingestellt, dass es die Box auch nicht überfordert. Abgesehen von den verrückten Werten, die ich oben sehe, vermute ich es nicht wirklich (5,1%) Alles in allem ist die Speichernutzung in Ordnung. Es ist ein VPS mit 768 MB RAM. Ich werde auf den nr_hugepages nachlesen und es versuchen, danke!

— Kyle Brantley

@ewwhite zuweisen, dass viele riesige Seiten die Box töten würden. Die Box hat nur 768 MB RAM und mit der Standardgröße von 2 MB würde dies 2 GB große Seiten zuweisen. Die Box würde damit nicht umgehen können und würde sofort sterben.

— Patrick

Aktualisiert. Der Wert sollte jedoch von Null erhöht werden.

— ewwhite

Es ist immer noch komplizierter. Sie müssen die Berechtigungen für große Seiten festlegen, und MySQL muss so konfiguriert sein, dass große Seiten verwendet werden. Andernfalls weisen Sie sie nur ohne Grund zu.

— Patrick

In der Grafik sind keine Daten verfügbar, vom Start des OOM-Killers bis zum Ende. Ich glaube an den Zeitrahmen, in dem der Graph unterbrochen wird, dass der Speicherverbrauch tatsächlich ansteigt und kein Speicher mehr verfügbar ist. Andernfalls würde der OOM-Killer nicht verwendet. Wenn Sie sich das Diagramm mit dem freien Speicher ansehen, nachdem der OOM-Killer gestoppt wurde, können Sie sehen, dass es von einem höheren Wert als zuvor abfällt. Zumindest hat es seine Arbeit richtig gemacht und Speicher freigegeben.

Beachten Sie, dass Ihr Swap Space bis zum Neustart fast voll ausgelastet ist. Das ist fast nie gut und ein sicheres Zeichen, dass nur noch wenig freier Speicher übrig ist.

Der Grund, warum für diesen bestimmten Zeitraum keine Daten verfügbar sind, liegt darin, dass das System mit anderen Dingen zu beschäftigt ist. "Lustige" Werte in Ihrer Prozessliste können nur ein Ergebnis sein, keine Ursache. Es ist nicht ungewöhnlich.

Überprüfen Sie /var/log/kern.log und / var / log / messages. Welche Informationen finden Sie dort?

Wenn die Protokollierung ebenfalls gestoppt wurde, versuchen Sie es mit anderen Dingen. Speichern Sie die Prozessliste etwa jede Sekunde in einer Datei, genau wie die Informationen zur Systemleistung. Führen Sie es mit hoher Priorität aus, damit es (hoffentlich) seine Arbeit weiterhin erledigen kann, wenn die Last ansteigt. Wenn Sie jedoch keinen Preempt-Kernel haben (manchmal als "Server" -Kernel bezeichnet), haben Sie in dieser Hinsicht möglicherweise kein Glück.

Ich denke, Sie werden feststellen, dass die Prozesse, die zum Zeitpunkt des Beginns Ihrer Probleme die meisten CPU% verbrauchen, die Ursache sind. Ich habe weder rsyslogd noch mysql so gesehen. Wahrscheinlicher sind Java-Apps und GUI-gesteuerte Apps wie ein Browser.

— aseq
quelle

In dieser Lücke befinden sich keine Daten, da die Belastung der Box so absurd hoch ist, dass alles, einschließlich des Überwachungsagenten, zum Stillstand kommt. Der Agent selbst wurde in der Zeit des Beinahe-Todes nie getötet, konnte jedoch auch keine Daten zurückmelden. Mein Tauschplatz war eigentlich in Ordnung. Vor dem Neustart wurden insgesamt ~ 130/512 MB verwendet. rsyslogd ist so konfiguriert, dass Protokolle an einen Netzwerkspeicherort gemeldet werden, an dem alles, was passiert ist, protokolliert wurde. Abgesehen davon, dass 408 Prozesse beendet wurden (von denen einige Apache-Kinder waren, die neu gestartet wurden), fiel nichts auf.

— Kyle Brantley

Ich werde möglicherweise alle paar Sekunden die vollständige Prozessliste in eine Datei (oder das Netzwerk) kopieren, wenn ich nicht wirklich herausfinden kann, was hier vor sich geht. Vielen Dank für die gute Idee.

— Kyle Brantley

Ja, das sollten Sie tun. Stellen Sie sicher, dass Sie auch die CPU-Auslastung jedes Prozesses aufzeichnen. Schauen Sie sich "top -b" (Batch-Modus) an. Der Prozess, der spitzt, könnte der Schuldige sein.

— Aseq