Diese Antwort erklärt die vom Kernel ergriffenen Maßnahmen, wenn eine OOM-Situation auftritt, basierend auf dem Wert von sysctl vm.overcommit_memory .
Wenn overcommit_memory auf 0 oder 1 gesetzt ist, overcommit aktiviert ist und Programme mehr Speicher zuweisen dürfen, als wirklich verfügbar ist.
Was passiert nun, wenn uns in dieser Situation der Speicher ausgeht? Wie funktioniert der OOM-Killer entscheiden, welcher Prozess zuerst beendet werden soll?
Akzeptierte Antwort:
Wenn der Speicher von Prozessen erschöpft ist und möglicherweise die Stabilität des Systems gefährdet, kommt der OOM-Killer ins Spiel.
HINWEIS: Es ist die Aufgabe des OOM-Killers, mit dem Töten von Prozessen fortzufahren, bis genügend Speicher für das reibungslose Funktionieren des restlichen Prozesses, den der Kernel auszuführen versucht, freigegeben ist.
Der OOM-Killer muss die Besten auswählen Prozess(e) zu töten. Am besten bezieht sich hier auf den Prozess, der beim Beenden den maximalen Speicher freigibt und auch am wenigsten wichtig für das System ist.
Das Hauptziel besteht darin, die geringste Anzahl von Prozessen zu beenden, um den angerichteten Schaden zu minimieren und gleichzeitig die Menge an freigegebenem Speicher zu maximieren.
Um dies zu erleichtern, verwaltet der Kernel einen oom_score für jeden der Prozesse. Sie können den oom_score sehen jedes Prozesses in /proc Dateisystem unter pid Verzeichnis.
$ cat /proc/10292/oom_score
Je höher der Wert von oom_score Je höher die Wahrscheinlichkeit eines Prozesses ist, vom OOM Killer getötet zu werden in einer Out-of-Memory-Situation.
Wie ist der OOM_Score berechnet?
In Davids Patch-Set sind die alten badness()-Heuristiken fast vollständig
verschwunden. Stattdessen verwandelt sich die Berechnung in eine einfache Frage, wie viel Prozent des verfügbaren Speichers vom Prozess verwendet werden. Wenn
das System als Ganzes wenig Speicher hat, dann ist „verfügbarer Speicher“
die Summe aller RAM- und Auslagerungsspeicher, die dem System zur Verfügung stehen.
Wenn stattdessen die OOM-Situation dadurch verursacht wird, dass der Arbeitsspeicher erschöpft ist, der
einem bestimmten CPU-Satz/einer bestimmten Kontrollgruppe erlaubt ist, dann ist „verfügbarer Arbeitsspeicher“ die Gesamtmenge
, die dieser Kontrollgruppe zugewiesen ist. Eine ähnliche Berechnung wird durchgeführt,
wenn durch eine Speicherrichtlinie auferlegte Grenzen überschritten wurden. In jedem Fall
wird die Speichernutzung des Prozesses als die Summe seines residenten
Satzes (die Anzahl der verwendeten RAM-Seiten) und seiner Swap-Nutzung angesehen.
Diese Berechnung ergibt als Ergebnis eine Prozent-mal-zehn-Zahl; Ein
Prozess, der jedes Byte des ihm zur Verfügung stehenden Speichers verwendet, erhält
eine Punktzahl von 1000, während ein Prozess, der überhaupt keinen Speicher verwendet, eine
Punktzahl von null erhält. Es gibt nur sehr wenige heuristische Optimierungen an dieser Punktzahl,
aber der Code subtrahiert immer noch einen kleinen Betrag (30) von der Punktzahl der
root-eigenen Prozesse aufgrund der Vorstellung, dass sie etwas mehr sind
wertvoller als benutzereigene Prozesse.
Eine weitere angewendete Optimierung besteht darin, den Wert hinzuzufügen, der in der Variable oom_score_adj jedes
Prozesses gespeichert ist, die über /proc angepasst werden kann.
Dieser Knopf ermöglicht die Anpassung der Attraktivität jedes Prozesses an
den OOM Killer im Userspace; Wenn Sie ihn auf -1000 setzen, werden OOM
-Kills vollständig deaktiviert, während die Einstellung auf +1000 dem Malen eines
großen Ziels auf den zugehörigen Prozess entspricht.
Referenzen
Verwandte:Nachteil bei der Verwendung einer Chroot im High Performance Computing?http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326