Wie bringe ich den Linux-OOM-Killer dazu, meinen Prozess nicht zu beenden?

28

Wie bringe ich den Linux-OOM-Killer dazu, meine Prozesse nicht zu beenden, wenn der physische Speicher knapp ist, aber genügend Auslagerungsspeicher vorhanden ist?

Ich habe das OOM-Töten deaktiviert und mit sysctl vm.overcommit_memory = 2 ein Overcommit durchgeführt.

Die VM verfügt über 3 GB absolut freien unfragmentierten Swap, und die Prozesse, die durch OOM beendet werden, haben eine maximale Speichernutzung von weniger als 200 MB.

Ich weiß, dass langfristiges Auslagern für die Leistung schrecklich sein wird, aber ich muss das Auslagern jetzt verwenden, um Funktionstests unter Valgrind durchzuführen, bei denen der Speicherbedarf viel größer ist.

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

Dies 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
Coder
quelle
8
Aus der Anrufverfolgung geht eindeutig hervor, dass der Kernel nicht über genügend Speicher verfügt. Der Grund, warum es nicht vertauscht wurde, kann viele verschiedene Ursachen haben, die alle zu lang sind, um sie in 500 Zeichen vollständig zu erklären. Aber es sieht so aus, als gäbe es keine wiedergewinnbaren Seiten ( all_unreclaimableist ja). Dies sind Seiten, die im RAM gesperrt sind, im Allgemeinen, weil sie vom Kernel angeheftet oder verwendet werden. Zu diesem Zeitpunkt war nichts, was Sie im RAM gelassen hatten, austauschbar. alles, was hätte getauscht werden können, war schon gewesen. Auch hier ist die Lösung mehr RAM.
Michael Hampton
1
@MichaelHampton Der Rest des Speichers wird von regulären Anwendungen verwendet. Warum kann der Kernel sie nicht zum Tauschen zwingen? Bitte antworten Sie auf meine Frage "Wenn das, was Sie sagen, wahr ist, wie könnte dann ein Prozess jemals verzweigen, nachdem der gesamte physische Speicher verwendet wurde?"
Coder
1
@MichaelHampton Ich deaktiviere das Gabeln und jetzt ruft fail2ban den Oom-Killer auf, wodurch meine Prozesse beendet werden. Was bringt Swap, wenn der Kernel es nicht nutzt? Was noch wichtiger ist, wie konfiguriere ich den Kernel so, dass ihm nicht mehr genügend Arbeitsspeicher zur Verfügung steht?
Coder
4
@MatthewIfe: Wenn du die Antwort kennst, poste sie bitte hier. Stack Exchange-Sites kommen allen Lesern zugute, nicht nur dem OP, der die Frage gestellt hat.
R ..
4
Das Austauschen in einer VM wird nicht als Best Practice angesehen. Ordnen Sie Ihrer VM mehr Arbeitsspeicher zu. Wenn Sie nicht mehr Speicher hinzufügen können, bringen Sie ihn intern in die physische Hardware, anstatt ihn in einem zu geringen Mietpreis zu belassen.
Criggie

Antworten:

36

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

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

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

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

Die andere Zeile lautet:

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

Die erste Zeile ist die für die Zuordnung zugewiesene GFP-Maske. Grundsätzlich wird beschrieben, was der Kernel tun darf / nicht darf, um diese Anforderung zu erfüllen. Die Maske zeigt eine Reihe von Standardflags an. Das letzte Bit, '2', gibt jedoch an, dass die Speicherzuweisung aus der HighMemZone stammen soll.

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

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(im Allgemeinen auch als Normalx86_64 bezeichnet) neigt dazu, Speicher für Zonen außerhalb der standardmäßigen 896-MB-Bereiche zuzuordnen, auf die der Kernel auf 32-Bit-Systemen direkt zugreifen kann. Auf x86_64 HighMem/Normalscheinen alle Seiten über 3GiB in der Größe abzudecken.

DMA32Enthält eine Zone, die für den Speicher verwendet wird, auf den auf 32-Bit-DMA-Geräten zugegriffen werden kann. Das heißt, Sie können sie mit 4-Byte-Zeigern adressieren. Ich glaube, DMAist für 16-Bit-DMA-Geräte.

Generell Normalwürde es auf Systemen mit wenig Arbeitsspeicher keine geben, da DMA32alle verfügbaren virtuellen Adressen bereits abgedeckt sind.

Der Grund, warum Sie OOM beenden, besteht darin, dass für eine HighMemZone mit 0 verfügbaren Seiten eine Speicherzuordnung vorhanden ist. Angesichts der Tatsache, dass der Out-of-Memory-Handler absolut keine Möglichkeit hat, die Verwendung von Seiten in dieser Zone durch Auslagern, Beenden anderer Prozesse oder eines anderen Tricks zu befriedigen, wird er von OOM-Killer einfach beendet.

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

  • Der aktuelle Speicher.
  • Der verfügbare Speicher.

Auf diese Weise können Sie Ihrem Server Hot-Add-Speicher hinzufügen, bis der verfügbare Speicher verfügbar ist. Ihr System erhält jedoch tatsächlich den aktuellen Speicher.

Wenn eine KVM-VM hochfährt, beginnt sie mit der maximal möglichen Speicherzuteilung (dem verfügbaren Speicher). Während der Boot-Phase des Systems krallt KVM diesen Speicher schrittweise mit seiner Ballonbildung zurück und lässt Sie stattdessen mit der aktuellen Speichereinstellung zurück.

Es ist meine Überzeugung, dass das hier passiert ist. Mit Linode können Sie den Speicher erweitern und beim Systemstart viel mehr.

Dies bedeutet, dass sich Normal/HighMemzu Beginn der Systemlebensdauer eine Zone befindet . Wenn der Hypervisor das Problem beseitigt, verschwindet die normale Zone zu Recht aus dem Speichermanager. Ich vermute jedoch, dass das Flag, das festlegt, ob die Zone für die Zuordnung verfügbar ist, nicht gelöscht wird, wenn dies erforderlich ist. Dies führt dazu, dass der Kernel versucht, eine Zuordnung von einer Zone vorzunehmen, die nicht vorhanden ist.

Um dies zu lösen, haben Sie zwei Möglichkeiten.

  1. Rufen Sie dies in den Kernel-Mailinglisten auf, um zu sehen, ob dies wirklich ein Fehler ist, ein erwartetes Verhalten oder überhaupt nichts mit dem zu tun hat, was ich sage.

  2. Bitten Sie Linode, den 'verfügbaren Speicher' auf dem System auf die gleiche 1GiB-Zuweisung wie den 'aktuellen Speicher' festzulegen. Somit steigt das System niemals in Ballons auf und erhält beim Booten niemals eine normale Zone, wodurch die Flagge frei bleibt. Viel Glück, dass sie das tun!

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

Ich mache hier ein paar fundierte Vermutungen und lese etwas zwischen den Zeilen, um diese Antwort zu finden, aber was ich sage, scheint den bereits skizzierten Tatsachen zu entsprechen.

Ich schlage vor, meine Hypothese zu testen und uns alle über das Ergebnis zu informieren.

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

Um Ihre Überschriftenfrage zu beantworten, verwenden Sie oom_score_adj(Kernel> = 2.6.36) oder für frühere Kernel (> = 2.6.11) oom_adj, siehe man proc

/ proc / [pid] / oom_score_adj (seit Linux 2.6.36) Diese Datei kann verwendet werden, um die Heuristik der Bösartigkeit anzupassen, die verwendet wird, um auszuwählen, welcher Prozess bei Bedingungen außerhalb des Arbeitsspeichers abgebrochen wird ...

/ proc / [pid] / oom_adj (seit Linux 2.6.11) Mit dieser Datei kann der Score angepasst werden, mit dem ausgewählt wird, welcher Prozess in einer OOM-Situation (Out-of-Memory) abgebrochen werden soll ...

Es gibt noch viel mehr zu lesen, aber wenn Sie oom_score_adj auf -1000 oder oom_adj auf -17 setzen, werden Sie das erreichen, was Sie wollen.

Das Problem ist, dass etwas anderes getötet wird. Vielleicht ist es besser festzustellen, warum OOM aufgerufen wird, und sich damit zu befassen.

user9517 unterstützt GoFundMonica
quelle
4
+1 für "Löse das zugrunde liegende Problem". Ist es möglich, dass die beleidigende Software (oder etwas anderes) gerade versucht hat, einen großen Teil des Kerns zu mallozieren? Es sind Anfragen nach mehr Speicher, die Dinge in Alarmbereitschaft versetzen und dazu neigen, den OOM-Killer auszulösen.
MadHatter unterstützt Monica am
11
@Coder: Die Linux-Kernel-Programmierer und der Linux-Kernel wissen eindeutig mehr als Sie. Ihr Prozess wurde abgebrochen, weil (trotz Ihrer Proteste) nicht genügend Speicher vorhanden war. Wenn Sie der Meinung sind, dass dies falsch ist, reichen Sie einen Fehlerbericht ein . Wenn Sie nicht auf das hören wollen, was klar kenntnisreiche Leute zu sagen haben, sollten Sie vielleicht für Ihre Unterstützung bezahlen, denn Ratschläge sind es wert, was Sie dafür bezahlen. Die Ratschläge werden nicht anders sein, aber Sie werden dafür bezahlt haben, also werden Sie es mehr schätzen.
user9517 unterstützt GoFundMonica
4
@Coder Ich bin leider kein Programmierer. Es gibt nur zwei Möglichkeiten: Der Kernel weiß nicht, wie man VM benutzt, und ein Programmierer hat einen Fehler gemacht, ich weiß, für welchen ich Geld habe.
MadHatter unterstützt Monica am
1
@coder Ich bin der "Jemand". Lassen Sie mich wissen, wie ich Kontakt aufnehmen kann.
Matthew Ife
1
@ MadHatter von 1000 Linux-Systemen kann ich Ihnen sagen: Es ist NICHT der Fall, dass man davon ausgehen könnte, dass es keine Probleme in der Speicherverwaltung oder einem anderen Teil des Kernels gibt. Dies ist keine hochwertige Unix-Plattform, und obwohl normalerweise alles einwandfrei funktioniert, ist es nicht sinnvoll, jede Seite dogmatisch zu betrachten.
Florian Heigl
12

Einige Gedanken (aus meinen obigen Kommentaren) und Links zu interessanten Lektüren über Ihre Situation:

Olivier Dulac
quelle
1
oom_adj ist nur für ältere Kernel gültig, neuere verwenden oom_score_adj.
user9517 unterstützt GoFundMonica
Haftungsausschluss: Ich kann nicht mehr detaillierte Informationen geben als die wenigen Links oben, da ich momentan nicht auf ein Linux-System zugreifen kann ... und es gibt so viele Dinge zu überprüfen. Vielleicht wird jemand einspringen und nette schrittweise Anleitungen bereitstellen ... (Die Serverfehler-Antwort, der letzte der "Good Reads" -Link in meiner Antwort, war so und ist eine unglaubliche Lektüre.)
Olivier Dulac
6

neben der erwähnten oom_score_adjErhöhung für den fraglichen Prozess (die wahrscheinlich nicht viel hilft - es würde es weniger wahrscheinlich machen, dass dieser Prozess ZUERST getötet wird, aber da dies nur speicherintensiv ist, wird das Prozesssystem wahrscheinlich nicht wiederhergestellt, bis es endlich ist getötet), hier sind ein paar Ideen zu optimieren:

  • Wenn Sie festlegen vm.overcommit_memory=2, können Sie auch den Wert vm.overcommit_ratioauf 90 einstellen (alternativ festlegen vm.overcommit_memory=0- siehe Kernel-Overcommit-Dokumente ).
  • Erhöhen Sie vm.min_free_kbytes, um immer einen Teil des physischen Arbeitsspeichers frei zu halten und damit die Wahrscheinlichkeit zu verringern, dass OOM etwas beenden muss (übertreiben Sie es jedoch nicht, da dies sofort OOM wird).
  • vm.swappinessauf 100 erhöhen (um das Austauschen des Kernels zu erleichtern )

Beachten Sie, dass , wenn Sie zu wenig Speicher haben die Aufgabe zu erfüllen, auch wenn Sie nicht OOM tun, es kann (oder auch nicht) werden extrem langsam - eine halbe Stunde Arbeit (auf System mit genügend RAM) kann mehrere Wochen leicht nehmen ( wenn RAM durch Swap ersetzt wird), um in extremen Fällen abzuschließen, oder sogar ganze VM hängen zu lassen. Dies ist insbesondere dann der Fall, wenn der Austausch bei klassischen Rotationsplatten (im Gegensatz zu SSDs) aufgrund von massiven zufälligen Lese- / Schreibvorgängen erfolgt, die sehr teuer sind.

Matija Nalis
quelle
3

Ich würde versuchen, overcommit zu aktivieren und zu sehen, ob das hilft. Ihr Prozess scheint innerhalb eines forkAufrufs fehlzuschlagen, der genauso viel virtuellen Speicher benötigt wie der ursprüngliche Prozess. overcommit_memory=2macht Ihren Prozess nicht immun gegen OOM-Killer, sondern verhindert lediglich, dass Ihr Prozess ihn auslöst, indem er zu viel zuweist. Andere Prozesse können nicht verwandte Zuordnungsfehler erzeugen (z. B. das Abrufen eines zusammenhängenden Speicherblocks), die den OOM-Killer weiterhin auslösen und Ihren Prozess entsorgen.

Alternativ (und genauer gesagt) können Sie, wie mehrere Kommentare andeuten, mehr RAM kaufen.

Dmitry Grigoryev
quelle
0

Kurzgeschichte - versuchen Sie es mit einer anderen Kernelversion. Ich habe ein System, das OOM-Fehler mit 4.2.0-x- und 4.4.0-x-Kerneln aufwies, aber nicht mit 3.19.0-x.

Lange Geschichte: (nicht zu lange!) Ich habe hier noch einen Compaq DC5000 im Einsatz - derzeit mit 512 MB RAM (und ein Teil davon, wie 32-128 MB, wird für das Onboard-Video ausgegeben ..) NFS, ich habe einen Monitor angeschlossen, daher melde ich mich gelegentlich an (Ubuntu Classic, no Unity).

Über Ubuntu HWE habe ich eine Weile den 3.19.x-Kernel ausgeführt. Am Ende würde es 200-300MB an Material austauschen, aber anscheinend war es unbenutztes Material, es würde keine Swap-Aktivität geben, wenn ich es später eintauschen müsste, soweit ich das beurteilen konnte.

4.2.0-x-Kernel und jetzt 4.4.0-x-Kernel, ich kann ein klobiges NFS-Schreiben starten, nur 220 MB in den Swap (dh 1,3 GB frei), und es wird beginnen, OOM Dinge zu töten. Ich werde nicht behaupten, dass es sich um einen Kernel-Bug oder ein "Tuning-Problem" handelt (wie eine 64-MB-Reserve, die normalerweise in Ordnung ist, aber auf einem System mit etwa 400 MB zu hoch ist?).

Keine Respektlosigkeit gegenüber denen, die sagen, dass es irgendwie kaputt geht, nur weil er erwartet, Swap zu verwenden; Bei allem Respekt liegen Sie falsch. Es wird nicht schnell gehen, aber ich habe auf einigen 512MB-1GB-Systemen 1 oder 2GB in den Swap gesteckt. Natürlich sind einige Arten von mlock-Software eine Menge RAM, aber in meinem Fall (da ich die gleiche Software nur auf einem anderen Kernel ausführe) ist dies eindeutig nicht der Fall.

user367995
quelle