Frage Wie bekomme ich den Linux OOM Killer, um meinen Prozess nicht zu beenden?


Wie bekomme ich den Linux OOM-Killer, um meine Prozesse nicht zu beenden, wenn der physische Speicher gering ist, aber viel Swap-Speicherplatz vorhanden ist?

Ich habe das Ausschalten von OOM und das Übercommit mit sysctl vm.overcommit_memory = 2 deaktiviert.

Die VM verfügt über 3 GB absolut kostenlosen unfragmentierten Swap und die Prozesse, die OOM getötet wird, hat eine maximale Speicherbelegung von weniger als 200 MB.

Ich weiß, dass Langzeit-Swapping für die Leistung schrecklich ist, aber ich muss den Swap sofort verwenden, um Funktionstests unter valgrind durchzuführen, wo die Speicheranforderungen viel größer sind.

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar  7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar  7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar  7 02:43:11 myhost kernel: Call Trace:
Mar  7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar  7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar  7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar  7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar  7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar  7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar  7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar  7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar  7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar  7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar  7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar  7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar  7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar  7 02:43:11 myhost kernel: Mem-Info:
Mar  7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar  7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar  7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar  7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar  7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar  7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar  7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
 mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar  7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar  7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB
Mar  7 02:43:11 myhost kernel: 71 total pagecache pages
Mar  7 02:43:11 myhost kernel: 42 pages in swap cache
Mar  7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar  7 02:43:11 myhost kernel: Free swap  = 3118172kB
Mar  7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar  7 02:43:11 myhost kernel: 262014 pages RAM
Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar  7 02:43:11 myhost kernel: 8149 pages reserved
Mar  7 02:43:11 myhost kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
Mar  7 02:43:11 myhost kernel: [ 2054]     0  2054     5101        1      15       4      283             0 upstart-udev-br
Mar  7 02:43:11 myhost kernel: [ 2063]     0  2063    12362        1      28       4      184         -1000 systemd-udevd
Mar  7 02:43:11 myhost kernel: [ 3342]   102  3342     9780        1      23       3       89             0 dbus-daemon
Mar  7 02:43:11 myhost kernel: [ 3423]     0  3423    10864        1      26       3       85             0 systemd-logind
Mar  7 02:43:11 myhost kernel: [ 3441]     0  3441    15344        0      34       3      184         -1000 sshd
Mar  7 02:43:11 myhost kernel: [ 3450]     0  3450     4786        0      14       3       43             0 atd
Mar  7 02:43:11 myhost kernel: [ 3451]     0  3451     5915        0      17       4       65             0 cron
Mar  7 02:43:11 myhost kernel: [ 3457]   101  3457    63962        0      28       3      202             0 rsyslogd
Mar  7 02:43:11 myhost kernel: [ 3516]     0  3516     3919        1      13       3      156             0 upstart-file-br
Mar  7 02:43:11 myhost kernel: [ 3518]     0  3518     4014        0      13       3      265             0 upstart-socket-
Mar  7 02:43:11 myhost kernel: [ 3557]     0  3557    66396        0      32       3     1802             0 fail2ban-server
Mar  7 02:43:11 myhost kernel: [ 3600]     0  3600     3956        1      13       3       39             0 getty
Mar  7 02:43:11 myhost kernel: [ 3601]     0  3601     3198        1      12       3       37             0 getty
Mar  7 02:43:11 myhost kernel: [ 3673]     0  3673    26411        1      55       3      252             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3740]  1000  3740    26411        1      52       3      253             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3741]  1000  3741     5561        0      16       3      431             0 bash
Mar  7 02:43:11 myhost kernel: [ 3820]   103  3820     7863        1      21       3      152             0 ntpd
Mar  7 02:43:11 myhost kernel: [ 3837]  1000  3837    31990        0      58       4    12664             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3841]  1000  3841    32006        0      59       4    12812             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3844]  1000  3844    31950        0      57       4    12035             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3849]  1000  3849    31902        0      56       4    11482             0 memcheck-amd64-
Mar  7 02:43:11 myhost kernel: [ 3853]  1000  3853     1087        0       7       3       27             0 lsof
Mar  7 02:43:11 myhost kernel: [ 3854]     0  3854    26140        5      55       3      230             0 sshd
Mar  7 02:43:11 myhost kernel: [ 3855]   104  3855    15699        0      33       3      202             0 sshd
Mar  7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar  7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB

Das ist / proc / meminfo

MemTotal:        1015460 kB
MemFree:          277508 kB
MemAvailable:     322032 kB
Buffers:            8336 kB
Cached:            42208 kB
SwapCached:        46088 kB
Active:            58844 kB
Inactive:         116100 kB
Active(anon):      34784 kB
Inactive(anon):    89620 kB
Active(file):      24060 kB
Inactive(file):    26480 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       3334140 kB
SwapFree:        3215756 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:        121128 kB
Mapped:            15072 kB
Shmem:                 4 kB
Slab:              22668 kB
SReclaimable:       8028 kB
SUnreclaim:        14640 kB
KernelStack:        2016 kB
PageTables:         2532 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3841868 kB
Committed_AS:     380460 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
DirectMap4k:       14208 kB
DirectMap2M:     1034240 kB
DirectMap1G:           0 kB

26
2018-03-07 08:00


Ursprung


Es ist offensichtlich, dass der Kernel nicht genügend Speicher hatte. Warum es nicht ausgetauscht wurde, kann viele verschiedene Ursachen haben, von denen alle zu lang sind, um sie vollständig in 500 Zeichen zu erklären. Aber Ihre sieht so aus, als gäbe es keine zurückforderbaren Seiten (all_unreclaimable ist ja). Dies sind Seiten, die im RAM gesperrt sind, im Allgemeinen, weil sie vom Kernel gepinnt oder verwendet werden. Nichts, was Sie im RAM hatten, war zu dieser Zeit austauschbar. alles das könnte wurden schon ausgelagert. Auch hier ist die Lösung mehr RAM. - Michael Hampton♦
@MichaelHampton Der Rest des Speichers wird von regulären Anwendungen verwendet. Warum kann der Kernel sie nicht zum Tauschen schieben? Bitte antworten Sie auf meine Frage "Wenn das, was Sie sagen, wahr ist, wie könnte dann irgendein Prozess jemals ablaufen, nachdem der gesamte physische Speicher verwendet wurde?" - Coder
Aber das machst du nicht. Du bist dramatisch Überschreiten Sie die Menge an Speicher, die Sie haben! Wie auch immer, das führt offensichtlich nicht weiter, also bin ich fertig. - Michael Hampton♦
@ MatthewIfe: Wenn du die Antwort kennst, poste es bitte hier. Stack Exchange-Sites sind für alle, die lesen, nicht nur die OP, die die Frage gestellt. - R..
Der Austausch einer VM gilt nicht als Best Practice. Weisen Sie Ihrer VM mehr realen Speicher zu. Wenn Sie nicht mehr Speicher hinzufügen können, bringen Sie es intern zu physischer Hardware, anstatt es in einem zu kleinen Mietpreis zu belassen. - Criggie


Antworten:


Dies scheint ein Problem in der Kombination von zwei Faktoren zu sein:

  • Verwenden einer virtuellen Maschine
  • Ein möglicher Kernel-Fehler.

Dies ist teilweise eine der Zeilen, die beschreiben, warum dies geschieht:

Mär 7 02:43:11 myhost kernel: memcheck-amd64-oom-killer aufgerufen: gfp_mask = 0x24002c2, order = 0, oom_score_adj = 0

Die andere Zeile ist dies:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| Die erste Zeile ist die GFP-Maske, die für die Zuweisung zugewiesen wurde. Es beschreibt im Grunde, was der Kernel tun darf / darf, um diese Anfrage zu erfüllen. Die Maske zeigt eine Reihe von Standardflaggen an. Das letzte Bit, '2', zeigt jedoch an, dass die Speicherzuweisung von der HighMem Zone.

Wenn Sie sich die OOM-Ausgabe genau ansehen, sehen Sie keine HighMem/Normal Zone existiert tatsächlich.

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem (allgemein auch genannt Normal auf x86_64) neigt dazu, Speicher für Zonen außerhalb der Standard-896MiB-Bereiche direkt Kernel zugänglich auf 32-Bit-Systemen. Auf x86_64 HighMem/Normal scheint alle Seiten über 3GiB abzudecken.

DMA32 enthält eine Zone, die für Speicher verwendet wird, auf den auf 32-Bit-DMA-Geräten zugegriffen werden könnte, dh Sie können sie mit 4-Byte-Zeigern adressieren. Ich glaube DMA ist für 16-Bit-DMA-Geräte.

Im Allgemeinen auf Systemen mit wenig Speicher Normal würde nicht existieren, angesichts dessen DMA32 deckt bereits alle verfügbaren virtuellen Adressen ab.

Der Grund für das Beenden von OOM liegt darin, dass eine Speicherzuweisung für a besteht HighMem Zone mit 0 Seiten verfügbar. Angesichts der Tatsache, dass der "out of memory" -Handler absolut keine Möglichkeit hat, diese Zone so zu gestalten, dass Seiten durch Tausch, andere Prozesse oder andere Tricks benutzt werden, tötet der OOM-Killer ihn.

Ich glaube, dass dies durch das Hochfahren der Host-VM beim Hochfahren verursacht wird. Auf KVM-Systemen können zwei Werte festgelegt werden.

  • Der aktuelle Speicher
  • Der verfügbare Speicher.

Die Funktionsweise besteht darin, dass Sie Speicher bis zu dem verfügbaren Arbeitsspeicher hinzufügen können. Ihr System erhält jedoch tatsächlich den aktuellen Speicher.

Wenn eine KVM-VM hochfährt, beginnt sie mit der maximal möglichen Zuteilung von Speicher (verfügbarer Speicher). Sukzessive während der Boot-Phase des Systems krallt KVM diesen Speicher mit seiner Ballooning-Funktion zurück und überlässt Ihnen stattdessen die aktuelle Speichereinstellung, die Sie haben.

Es ist meine Überzeugung, was hier passiert ist. Mit Linode können Sie den Arbeitsspeicher erweitern, sodass Sie beim Systemstart viel mehr haben.

Dies bedeutet, dass es a Normal/HighMem Zone zu Beginn der Lebensdauer des Systems. Wenn der Hypervisor ihn wegbewegt, verschwindet die normale Zone ordnungsgemäß aus dem Speichermanager. Aber ich vermute, dass die Flag-Einstellung, ob die Zone verfügbar ist, zu reservieren ist nicht gelöscht, wenn es sollte. Dies führt dazu, dass der Kernel versucht, aus einer Zone, die nicht existiert, zuzuordnen.

In Bezug auf die Lösung haben Sie zwei Möglichkeiten.

  1. Bring dies auf die Kernel-Mailinglisten, um zu sehen, ob das wirklich ein Bug ist, Verhalten erwartet wird oder überhaupt nichts mit dem zu tun hat, was ich sage.

  2. Fordern Sie an, dass linode den 'verfügbaren Speicher' auf dem System auf die gleiche 1GiB-Zuweisung wie den 'aktuellen Speicher' einstellt. Daher wird das System niemals in Ballons versetzt und erhält niemals eine Normalzone beim Booten, wodurch die Flagge frei bleibt. Viel Glück, sie dazu zu bringen!

Sie sollten in der Lage sein zu testen, dass dies der Fall ist, indem Sie Ihre eigene VM in KVM-Einstellung für 6GiB, aktuell zu 1GiB einrichten und Ihren Test mit demselben Kernel ausführen, um zu sehen, ob dieses Verhalten auftritt. Wenn dies der Fall ist, ändern Sie die Einstellung "Verfügbar" so, dass sie dem Strom von 1GiB entspricht, und wiederholen Sie den Test.

Ich mache hier ein paar Vermutungen und lese etwas zwischen den Zeilen, um auf diese Antwort zu kommen, aber was ich sage, scheint zu den bereits umrissenen Fakten zu passen.

Ich schlage vor, meine Hypothese zu testen und uns alle das Ergebnis wissen zu lassen.


32
2018-03-08 11:35



Das ist eine gründliche (und gut erklärte) Antwort! - Olivier Dulac
Ja, ausgezeichnete Antwort ... Viel hilfreicher als die Kommentare der Leute, dass "das OP blindlings den Kernel-Nachrichten vertrauen sollte", ohne zu erklären, warum der verfügbare Swap-Space nicht genutzt wird. - Michael Martinez


Um Ihre Headline-Frage zu beantworten, verwenden Sie oom_score_adj(Kernel> = 2.6.36) oder für frühere Kernel (> = 2.6.11) oom_adjSiehst du den Menschen? Proz 

/ proc / [pid] / oom_score_adj (seit Linux 2.6.36)   Diese Datei kann verwendet werden, um die Schlechte-Heuristik anzupassen, die verwendet wird, um auszuwählen, welcher Prozess bei Nicht-Arbeitsspeicher-Bedingungen beendet wird ...

/ proc / [pid] / oom_adj (seit Linux 2.6.11)   Diese Datei kann verwendet werden, um den Punktestand anzupassen, der verwendet wird, um auszuwählen, welcher Prozess in einer Out-of-Memory (OOM) -Situation beendet werden soll ...

Es gibt noch viel mehr zu lesen, aber das Setzen von oom_score_adj auf -1000 oder oom_adj auf -17 wird erreichen, was Sie wollen.

Das Problem ist, dass noch etwas getötet wird. Vielleicht wäre es besser zu bestimmen, warum OOM aufgerufen wird und damit umzugehen.


29
2018-03-07 08:21



Da es 3 Gigs Free Swap gibt denke ich, dass der OOM Killer nicht ausgelöst werden sollte. Ich möchte, dass es nicht ausgelöst wird. Für diesen Test kann ich keine der Prozesse auf dem Host töten lassen, und sie sollten nicht getötet werden, weil es so viel freien Austausch gibt. - Coder
+1 für "das zugrunde liegende Problem lösen". Ist es möglich, dass die anstößige Software (oder etwas anderes) gerade versucht hat, einen großen Teil des Kerns zu malloc zu machen? Es ist Anfragen für Mehr Erinnerung, die Dinge in den roten Alarmbereich bringt, die dazu neigen, den OOM-Killer auszulösen. - MadHatter
@Coder: Die Linux-Kernel-Programmierer und der Linux-Kernel wissen eindeutig mehr als du. Ihr Prozess wurde getötet, weil (trotz Ihrer Proteste) nicht genügend Speicher vorhanden war. Wenn Sie das für falsch halten, dann legen Sie a ein Fehlerbericht. Wenn Sie nicht darauf hören, was die Leute, die eindeutig kenntnisreich sind, zu sagen haben, dann sollten Sie vielleicht für Ihre Unterstützung bezahlen, denn Beratung ist es wert, was Sie dafür bezahlen. Der Rat wird nicht anders sein, aber Sie werden dafür bezahlt haben, so wird es mehr wert sein. - Iain
@Coder Ich bin leider kein Programmierer. Es ist nur, dass zwischen zwei Möglichkeiten gefangen: dass der Kernel nicht weiß, wie man VM verwendet, und dass ein Programmierer einen Fehler gemacht hat, weiß ich, in welchem ​​mein Geld ist. - MadHatter
@coder Ich bin der "Jemand". Lass mich wissen, wie du in Kontakt treten kannst. - Matthew Ife


Einige Gedanken (von meinen Kommentaren oben) und Links zu interessanten liest über Ihre Situation:


11
2018-03-07 12:00



oom_adj ist nur für ältere Kernel gültig, neuere verwenden oom_score_adj. - Iain
@Iain: Danke, ich habe das in die Antwort eingefügt. - Olivier Dulac
Haftungsausschluss: Ich kann keine detaillierteren Informationen geben als die paar obigen Links, da ich im Moment kein Linux-System aufrufen kann ... und es gibt so viele Dinge zu prüfen. Vielleicht wird jemand reingehen und nette Schritt-für-Schritt-Prozeduren bereitstellen ... (die Antwort von serverfault, der letzte Link zum "Guten Lesen" in meiner Antwort, war so und ist eine unglaubliche Lektüre.) - Olivier Dulac


neben erwähnt oom_score_adj Erhöhung für den fraglichen Prozess (was wahrscheinlich nicht viel helfen wird - es würde es weniger wahrscheinlich machen, dass dieser Prozess zuallererst getötet würde, aber da nur das speicherintensive Prozesssystem sich wahrscheinlich nicht erholen wird, bis es schließlich getötet wird) , hier sind ein paar Ideen, die du ändern kannst:

  • wenn du es einstellst vm.overcommit_memory=2, auch zwicken vm.overcommit_ratio zu vielleicht 90 (alternativ, eingestellt vm.overcommit_memory=0 - sehen Kernel überschreibt Dokumente)
  • erhöhen, ansteigen vm.min_free_kbytes um immer etwas physisches RAM frei zu halten und somit die Wahrscheinlichkeit zu reduzieren, dass OOM etwas töten muss (aber übertreibe es nicht, da es OOM sofort zerstören wird).
  • erhöhen, ansteigen vm.swappiness bis 100 (zu machen Kernelwechsel leichter)

Beachten Sie, dass, wenn Sie zu wenig Speicher haben, um die Aufgabe zu erledigen, auch wenn Sie nicht OOM, es tun kann (oder nicht) wird extrem langsam - eine halbe Stunde Job (auf einem System mit genügend RAM) kann leicht mehrere Wochen dauern (wenn RAM durch Swap ersetzt wird), um im Extremfall abzuschließen, oder sogar ganze VM hängen. Dies ist insbesondere dann der Fall, wenn Swap auf klassischen Rotationsdisketten (im Gegensatz zu SSDs) aufgrund massiver zufälliger Lese- / Schreibvorgänge erfolgt, die für sie sehr teuer sind.


6
2018-03-07 22:39





Ich würde versuchen, Overcommit zu ermöglichen und sehen, ob das hilft. Ihr Prozess scheint innerhalb eines zu versagen fork Aufruf, der so viel virtuellen Speicher benötigt wie der ursprüngliche Prozess hatte. overcommit_memory=2 macht Ihren Prozess nicht immun gegen OOM-Killer, er verhindert nur, dass Ihr Prozess ihn auslöst, indem er zu viel zuweist. Andere Prozesse können zu nicht zugeordneten Zuordnungsfehlern führen (z. B. zum Aufrufen eines zusammenhängenden Speicherblocks), die immer noch den OOM-Killer auslösen und Ihren Prozess beseitigen.

Alternativ (und mehr auf den Punkt), wie mehrere Kommentare vorschlagen, kaufen Sie mehr RAM.


3
2018-03-07 14:02





Kurzgeschichte - probiere eine andere Kernel-Version. Ich habe ein System, das OOM-Fehler mit 4.2.0-x und 4.4.0-x-Kernel zeigte, aber nicht mit 3.19.0-x.

Lange Geschichte: (nicht zu lange!) Ich habe noch einen Compaq DC5000 im Dienst - derzeit mit 512MB RAM (und ein Teil davon, wie 32-128MB, die an das Onboard-Video gegeben werden ..). Hauptsächlich mit NFS, habe ich einen Monitor angeschlossen dazu werde ich mich gelegentlich einloggen (Ubuntu Classic, keine Unity.)

Über Ubuntu HWE habe ich den 3.19.x-Kernel eine ganze Weile laufen lassen; Am Ende würde es wie 200-300 MB ausladen, aber anscheinend waren es ungenutzte Sachen, es würde keine Swap-Aktivität geben, die ich später eintauschen musste, soweit ich das beurteilen konnte.

4.2.0-x kernel und jetzt 4.4.0-x kernel, ich kann einen Chunky NFS schreiben, nur 220MB in den Swap (d. H. 1,3GB frei), und es startet OOM Dinge zu töten. Ich werde nicht behaupten, dass es ein Kernel-Bug oder "Tuning-Problem" ist (wie eine 64MB Reserve, die normalerweise gut ist, aber zu hoch auf einem ~ 400MB oder so System?)

Keine Respektlosigkeit gegenüber denen, die sagen, dass es irgendwie kaputt ist, nur weil er erwartet, dass er Swap benutzt; bei allem Respekt, du liegst falsch. Es wird nicht schnell gehen, aber ich habe auf einigen 512MB-1GB-Systemen 1 oder 2 GB in den Swap gesteckt. Natürlich sind einige Arten von Software mlock ein Haufen RAM, aber in meinem Fall (da ich die gleiche Software nur auf einem anderen Kernel laufen lasse) ist das eindeutig nicht der Fall.


0
2017-07-30 03:05