Der Grund, warum der OOM-Killer nicht automatisch aufgerufen wird, liegt darin, dass das System, wenn auch vollständig verlangsamt und nicht mehr reagiert, bereits bei knappem Speicher y, hat die Out-of-Memory-Situation noch nicht erreicht.
Vereinfacht gesagt enthält der fast volle RAM 3 Arten von Daten:
- Kerneldaten, das ist wichtig
- Seiten mit wesentlichen Prozessdaten (z. B. alle Daten, die der Prozess nur im RAM erstellt)
- Seiten mit nicht wesentlichen Prozessdaten (z. B. Daten wie der Code von ausführbaren Dateien, für die es eine Kopie auf der Festplatte/im Dateisystem gibt und die, obwohl sie derzeit dem Speicher zugeordnet sind, bei der Verwendung von der Festplatte "neu gelesen" werden könnten )
In einer Situation mit Speichermangel ist der Linux-Kernel, soweit ich das beurteilen kann, kswapd0 Kernel-Thread, um Datenverlust und Funktionsverlust zu verhindern, kann 1. und 2. nicht wegwerfen, hat aber die Freiheit, diese in Speicherdateien abgebildeten Daten zumindest vorübergehend aus dem RAM zu entfernen, d. h. aus Prozessen, die derzeit nicht ausgeführt werden.
Obwohl dies ein Verhalten ist, das Festplatten-Thrashing beinhaltet, kann das ständige Wegwerfen von Daten und erneutes Lesen von der Festplatte als hilfreich angesehen werden, da es das notwendige Entfernen/Beenden eines Prozesses und das Freigeben-aber-auch- Wenn er sein Gedächtnis verliert, hat er ein High Preis:Leistung.
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
ist eindeutig IO teuer und das System wird wahrscheinlich nicht mehr reagieren, obwohl es technisch noch nicht vollständig ausgelaufen ist der Erinnerung.
Aus Benutzersicht scheint es jedoch, dass es aufgehängt/eingefroren ist und die daraus resultierende nicht reagierende Benutzeroberfläche nicht wirklich vorzuziehen ist, anstatt den Prozess einfach zu beenden (z beginnen mit.)
Hier scheint, wie die Frage angedeutet hat, der Magic SysRq-Tastenauslöser zum manuellen Starten des OOM großartig zu sein, da der Magic SysRq weniger von der Nichtreaktion des Systems beeinflusst wird.
Es kann zwar Anwendungsfälle geben, in denen es wichtig ist, die Prozesse überhaupt zu erhalten (Leistung ) kostet, für einen Desktop ist es wahrscheinlich, dass Benutzer den OOM-Killer der eingefrorenen Benutzeroberfläche vorziehen würden. In dieser Antwort auf Stackoverflow gibt es einen Patch, der behauptet, sauber zugeordnete fs-gesicherte Dateien in einer solchen Situation aus dem Speicher auszunehmen.
Sie können sich die Datei /sys/fs/cgroup/memory/memory.oom_control während eines Belastungstests ansehen.
oder
Sie können sich das Datum der letzten Änderung ansehen, um zu sehen, ob es etwa zum Zeitpunkt der letzten Sperrung geändert wurde. Dies wird Ihnen sagen, ob es überhaupt versucht hat, seine Aufgabe zu erfüllen.
under_oom 0
Das ist Ihr Problem:
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
Wenn auf 1 gesetzt, bedeutet dies, dass es unter Raumkontrolle steht. Ermöglicht.
Wenn es auf 0 gesetzt ist, ist es nicht unter Raumkontrolle. Deaktiviert.