Warum kann der OOM-Killer nicht einfach den Prozess beenden, der zu viel verlangt?

Hier wird erklärt , dass der OOM-Killer über konfiguriert werden kann overcommit_memoryund dass:

2 = kein Overcommit. Zuweisungen schlagen fehl, wenn zu viel verlangt wird.
0, 1 = Overcommit (heuristisch oder immer). Beenden Sie einige Prozesse basierend auf bestimmten Heuristiken, wenn tatsächlich auf zu viel Speicher zugegriffen wird.

Nun, ich kann das völlig falsch verstehen, aber warum gibt es keine Option (oder warum ist es nicht die Standardeinstellung), um genau den Prozess abzubrechen, der tatsächlich versucht, auf zu viel zugewiesenen Speicher zuzugreifen?

linux out-of-memory

— Martin Ba
quelle

Was ist, wenn ein kritischer Systemprozess zu viel Speicher benötigt?

— Lawrence

Erstens - das kann es. Das größte Problem bei dieser Frage ist jedoch, dass ein Prozess , der nach Speicher fragt, höchstwahrscheinlich gerade neu ausgeführt wird - oder mit anderen Worten, es handelt sich um einen neuen Prozess, der an einer sehr aktuellen Verarbeitung beteiligt ist. Würdest du lieber zulassen, dass dein nicht für 3 Tage geöffneter OOM-Client weiterhin Systemspeicher verschwendet, oder würdest du lieber, dass YouTube dieses Jahr irgendwann tatsächlich geladen wird? linuxatemyram.com

— mikeserv

Dies ist, was die no overcommitOption im Wesentlichen tut. Wenn ein Prozess zu viel Speicher benötigt, schlägt dies fehl. Wenn es nach dem Fehler sucht, wird es sich normalerweise selbst töten. Wenn dies nicht der Fall ist, wird wahrscheinlich ein Segmentierungsfehler ausgegeben, wenn versucht wird, den zurückgegebenen Nullzeiger zu dereferenzieren, und der Zeiger malloc()stürzt ab.

— Barmar

Beachten Sie, dass 2 no overcommitden genannten Quellen zufolge tatsächlich der Modus ist (z. B. kernel.org/doc/Documentation/vm/overcommit-accounting ). Ich denke, ich werde Ihre Frage entsprechend bearbeiten.

— Hans_Meine

Betrachten Sie dieses Szenario:

Sie haben 4 GB freien Speicher.
Ein fehlerhafter Prozess weist 3,999 GB zu.
Sie öffnen einen Task-Manager, um den außer Kontrolle geratenen Prozess abzubrechen. Der Task-Manager weist 0,002 GB zu.

Wenn der Prozess, der beendet wurde, der letzte Prozess ist, der Speicher anfordert, wird Ihr Task-Manager beendet.

Oder:

Sie haben 4 GB freien Speicher.
Ein fehlerhafter Prozess weist 3,999 GB zu.
Sie öffnen einen Task-Manager, um den außer Kontrolle geratenen Prozess abzubrechen. Der X-Server weist 0,002 GB für das Fenster des Task-Managers zu.

Jetzt wird dein X-Server getötet. Es hat das Problem nicht verursacht; es war nur "am falschen Ort zur falschen Zeit". Es war zufällig der erste Prozess, der mehr Speicher zugeteilt hat, als noch keiner übrig war, aber es war nicht der Prozess, der am Anfang den gesamten Speicher verbraucht hat.

— user253751
quelle

Um Ihr Beispiel zu erweitern, bedeutet dies, dass wenn ein Prozess 99,999% Ihres Speichers verbraucht hätte, Sie ihn niemals töten könnten, da alles, was ihn töten könnte, Speicher erfordern würde und sich selbst töten würde, bevor der fehlerhafte Prozess getötet werden könnte!

— Schlitten

Wohlgemerkt, das ist die Linux-Philosophie, keine notwendige Tatsache. Windows 3.0 behebt das Problem, indem genügend Speicher für die OOM-Verarbeitung einschließlich der erforderlichen Dialogfelder reserviert ist.

— MSalters

@MSalters: Das trifft jedoch nicht wirklich auf das Beispiel zu. Das Beispiel handelte von einem Prozess, der fast den gesamten Speicher reserviert hat , d. H. nicht genug, um sich OOM töten zu lassen. Offensichtlich muss auf jedem Betriebssystem genügend Speicher für die OOM-Verarbeitung reserviert sein. Der Prozess, der die OOM-Behandlung aufruft, ist jedoch der nächste Prozess, der Speicherplatz reserviert, und nicht der Prozess, der sich schlecht verhält. Es sei denn, Sie haben damit gemeint, dass in Windows 3.0 immer genügend Speicher für die Ausführung des Task-Managers reserviert war oder der OOM-Handler den Benutzer immer aufgefordert hat, den Vorgang abzubrechen. (Welche! = Töten den Prozess der Beleidigung)

— Aleksi Torhamo

@ AleksiTorhamo: Ich meinte in der Tat letzteres. Windows 3.0 hatte keinen vollwertigen Task-Manager, sondern die berühmten blauen Bildschirme, deren Speicher vorab zugewiesen wurde.

— MSalters