Es kann.
Es gibt zwei verschiedene Speicherbedingungen, denen Sie in Linux begegnen können. Auf was Sie stoßen, hängt vom Wert von sysctl vm.overcommit_memory ab (/proc/sys/vm/overcommit_memory )
Einführung:
Der Kernel kann sogenanntes 'Memory Overcommit' durchführen. Dies ist der Fall, wenn der Kernel Programmen mehr Speicher zuweist, als wirklich im System vorhanden ist. Dies geschieht in der Hoffnung, dass die Programme nicht den gesamten Speicher verwenden, den sie zugewiesen haben, da dies ziemlich häufig vorkommt.
overcommit_memory =2
Wenn overcommit_memory auf 2 eingestellt ist , führt der Kernel keinerlei Overcommit durch. Wenn einem Programm stattdessen Speicher zugewiesen wird, wird ihm der Zugriff auf diesen Speicher garantiert. Wenn das System nicht über genügend freien Speicher verfügt, um eine Zuordnungsanforderung zu erfüllen, gibt der Kernel nur einen Fehler für die Anforderung zurück. Es liegt am Programm, die Situation elegant zu handhaben. Wenn es nicht überprüft, ob die Zuweisung erfolgreich war, wenn es wirklich fehlgeschlagen ist, wird die Anwendung oft auf einen Segfault stoßen.
Im Falle des segfault sollten Sie eine Zeile wie diese in der Ausgabe von dmesg finden :
[1962.987529] myapp[3303]: segfault at 0 ip 00400559 sp 5bc7b1b0 error 6 in myapp[400000+1000]
Die at 0 bedeutet, dass die Anwendung versucht hat, auf einen nicht initialisierten Zeiger zuzugreifen, was das Ergebnis eines fehlgeschlagenen Speicherzuweisungsaufrufs sein kann (aber nicht der einzige Weg).
overcommit_memory =0 und 1
Wenn overcommit_memory auf 0 eingestellt ist oder 1 , Overcommit ist aktiviert und Programme dürfen mehr Speicher zuweisen, als wirklich verfügbar ist.
Wenn jedoch ein Programm den zugewiesenen Speicher verwenden möchte, der Kernel jedoch feststellt, dass er nicht über genügend Speicher verfügt, muss es etwas Speicher zurückbekommen. Es versucht zunächst, verschiedene Speicherbereinigungsaufgaben durchzuführen, z als Leeren von Caches, aber wenn dies nicht ausreicht, wird ein Prozess beendet. Diese Terminierung wird vom OOM-Killer durchgeführt. Der OOM-Killer untersucht das System, um zu sehen, welche Programme welchen Speicher verwenden, wie lange sie laufen, wer sie ausführt und eine Reihe anderer Faktoren, um festzustellen, welches Programm getötet wird.
Nachdem der Prozess beendet wurde, wird der von ihm verwendete Speicher freigegeben, und das Programm, das gerade den Speichermangel verursacht hat, verfügt nun über den erforderlichen Speicher.
Aber auch in diesem Modus können Programmen weiterhin Zuweisungsanfragen verweigert werden. Wenn overcommit_memory ist 0 , versucht der Kernel nach bestem Wissen und Gewissen abzuschätzen, wann er mit dem Ablehnen von Zuweisungsanfragen beginnen sollte. Wenn er auf 1 gesetzt ist , ich bin mir nicht sicher, welche Bestimmung es verwendet, um zu bestimmen, wann es eine Anfrage ablehnen sollte, aber es kann sehr große Anfragen ablehnen.
Sie können sehen, ob der OOM-Killer beteiligt ist, indem Sie sich die Ausgabe von dmesg ansehen , und finden Sie Nachrichten wie:
[11686.043641] Out of memory: Kill process 2603 (flasherav) score 761 or sacrifice child
[11686.043647] Killed process 2603 (flasherav) total-vm:1498536kB, anon-rss:721784kB, file-rss:4228kB
Die Wahrheit ist, dass unabhängig davon, wie Sie es betrachten – ob Ihr Prozess aufgrund des Speichermanagers des Systems oder aufgrund von etwas anderem blockiert ist – es immer noch ist ein Käfer. Was ist mit all den Daten passiert, die Sie gerade im Speicher verarbeitet haben? Es hätte gespeichert werden sollen.
Während overcommit_memory= ist die allgemeinste Art, Linux OOM Management zu konfigurieren, es ist auch pro Prozess anpassbar wie:
echo [-+][n] >/proc/$pid/oom_adj
Mit -17 im obigen wird einen Prozess von der Speichermangelverwaltung ausschließen. Wahrscheinlich keine gute Idee im Allgemeinen, aber wenn Sie Fehler suchen, könnte es sich lohnen, dies zu tun - besonders wenn Sie wissen möchten, ob es OOM oder war dein Code. Eine positive Erhöhung der Zahl erhöht die Wahrscheinlichkeit, dass der Prozess bei einem OOM-Ereignis beendet wird, was es Ihnen ermöglichen könnte, die Widerstandsfähigkeit Ihres Codes in Situationen mit wenig Arbeitsspeicher besser zu stärken und sicherzustellen, dass Sie bei Bedarf ordnungsgemäß beendet werden.
Sie können die aktuellen Einstellungen des OOM-Handlers pro Prozess wie folgt überprüfen:
cat /proc/$pid/oom_score
Sonst könnten Sie Selbstmord begehen:
sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
Dadurch wird der Computer so eingestellt, dass er im Falle eines Speichermangels neu startet. Sie setzen den X oben auf die Anzahl der Sekunden, die der Computer nach einer Kernel Panic anhalten soll, bevor er neu startet. Dreh durch.
Und wenn Sie aus irgendeinem Grund entscheiden, dass es Ihnen gefällt, machen Sie es dauerhaft:
echo "vm.panic_on_oom=1" >> /etc/sysctl.conf
echo "kernel.panic=X" >> /etc/sysctl.conf