OOM Killer funktioniert nicht richtig, führt zu einem eingefrorenen Betriebssystem

Seit Jahren funktioniert der OOM-Killer meines Betriebssystems nicht mehr richtig und führt zu einem eingefrorenen System.
Wenn die Speichernutzung sehr hoch ist, kann das gesamte System stunden- oder sogar tagelang "einfrieren" (und zwar extrem langsam) , anstatt Prozesse abzubrechen, um den Speicher freizugeben. Das Maximum, das ich aufgezeichnet habe, sind 7 Tage, bevor ich mich zurückgebe, um einen Reset durchzuführen. Wenn die OOM erreicht werden soll, ist der iowait sehr hoch (~ 70%), bevor er nicht mehr messbar wird. Das Tool: hat gezeigt, dass alle Programme mit einem sehr hohen Durchsatz (pro Dutzend MB / s) von meiner Festplatte lesen. Was lesen diese Programme?

iotop

- Die Verzeichnishierarchie?
- Der ausführbare Code selbst?
Ich weiß nicht genau jetzt.

[bearbeitet] Als ich diese Nachricht schrieb (im Jahr 2017), verwendete ich ein aktuelles ArchLinux (4.9.27-1-lts), hatte das Problem jedoch bereits vor Jahren erfahren.
Ich habe das gleiche Problem mit verschiedenen Linux-Distributionen und verschiedenen Hardware-Konfigurationen erlebt.
Derzeit (2019) verwende ich ein aktuelles Debian 9.6 (4.9.0). Ich habe 16 GB physischen RAM, eine SSD, auf der mein Betriebssystem installiert ist, und keine Swap- Partition.

Aufgrund der Menge an RAM, die ich habe, möchte ich keine Swap-Partition aktivieren, da dies nur das Auftreten des Problems verzögern würde.
Wenn SSDs zu oft ausgetauscht werden, kann dies möglicherweise die Lebensdauer der Festplatte verkürzen.
Übrigens, ich habe es bereits mit und ohne Swap-Partition versucht. Es hat sich gezeigt, dass es das Auftreten des Problems nur verzögert, aber nicht die Lösung ist.

Für mich liegt das Problem darin, dass Linux wichtige Daten aus den Caches löscht , was zu einem eingefrorenen System führt, da es jedes Mal alles von der Festplatte lesen muss.

Ich frage mich sogar, ob Linux die ausführbaren Codeseiten von laufenden Programmen nicht löschen würde, was erklären würde, warum sich Programme, die normalerweise nicht viele Daten lesen, in dieser Situation so verhalten.

Ich habe verschiedene Dinge versucht, um dieses Problem zu beheben.
Einer war eingestellt /proc/sys/vm/min_free_kbytesauf 1000000(1 GB).
Da diese 1 GB frei bleiben sollten, dachte ich, dass dieser Speicher von Linux reserviert würde, um wichtige Daten zwischenzuspeichern.
Aber es hat nicht geklappt.

Außerdem glaube ich , nützlich , dass hinzufügen , auch wenn es in der Theorie groß klingen könnte, um die Größe des virtuellen Speichers auf die Größe des physikalischen Speichers zu beschränken, durch die Definition /proc/sys/vm/overcommit_memoryzu 2nicht anständig technisch möglich in meiner Situation, weil die Art von Anwendungen Ich verwende, benötigen mehr virtuellen Speicher, als sie aus bestimmten Gründen effektiv verwenden.
Laut Datei /proc/meminfoist der Commited_ASWert auf meinem System oft höher als das Doppelte des physischen RAM (16 GB, Commited_AS ist oft> 32 GB).

Ich habe dieses Problem mit erlebt /proc/sys/vm/overcommit_memoryauf seinen Standardwert: 0, und für eine Weile habe ich es definiert: 1, weil ich Programme bevorzugt durch die getötet werden OOM Killer nicht falsch verhalten , weil sie nicht die Rückgabewerte von überprüfen , mallocwenn die Zuweisungen werden abgelehnt.

Als ich im IRC über dieses Problem sprach , habe ich andere Linux-Benutzer getroffen, bei denen das gleiche Problem aufgetreten ist. Ich schätze, dass viele Benutzer davon betroffen sind.
Für mich ist dies nicht akzeptabel, da selbst Windows mit einer hohen Speichernutzung besser umgeht.

Wenn Sie weitere Informationen benötigen, haben Sie einen Vorschlag, sagen Sie mir bitte.

Dokumentation:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

Sie reden darüber:
Warum läuft der Linux-OOM-Killer nicht automatisch, sondern arbeitet mit sysrq-key?
Warum kann OOM-Killer manchmal keine Rohstoffschweine töten?
OOM-Killer vorladen
Ist es möglich, OOM-Killer beim erzwungenen Tauschen auszulösen?
Wie vermeide ich eine hohe Latenz in der Nähe der OOM-Situation?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

— M89
quelle

Ich denke, das ist, was Sie erwarten sollten, wenn Sie verprügeln, aber Sie nähern sich nicht wirklich 100% "verwendet", dh es gibt zu viel Speicherbedarf, der durch Dateien gesichert wird und als "Buff / Cache" gezählt wird. (Ach, diese Formulierung geht davon aus, dass Ihre tmpfs-Zuweisungen trivial sind, da diese als "Buff / Cache" angezeigt werden, aber nicht in ein physisches Dateisystem ausgelagert werden können). min_free_kbytesist nicht relevant, es ist keine Reserve für zwischengespeicherte Seiten. AFAICT Keines der vm-sysctls erlaubt es, Speicher speziell für zwischengespeicherte Seiten zu reservieren, dh die MAP_ANONYMOUS-Zuweisungen einzuschränken :(.

— sourcejedi

Ich habe seit Jahren erfolglos nach einer Lösung für genau dieses Problem gesucht. Ich glaube, das Problem ist mir zum ersten Mal aufgefallen, nachdem ich meine Festplatte durch eine SSD ersetzt habe, was auch zur Folge hatte, dass ich das Tauschen insgesamt deaktiviert habe. Ich kann jedoch nicht wirklich garantieren, dass es vor diesen Änderungen noch nie passiert ist. Ich bin übrigens auf Archlinux.

— Brunocodutra

Ich habe gerade in Arch Linux-Foren darüber geschrieben.

— Ignat Insarov

@ dsstorefile1 Danke, das werde ich versuchen. Aber wie könnte es den OOM-Killer sicher auslösen, wenn der Kernel es in dieser Situation nicht richtig kann?

— M89

Es hat geholfen, als Chrome es geschafft hat, mein gesamtes RAM durchzulaufen ... (obwohl ich schließlich auch eine echte Festplatten-Swap-Partition hinzugefügt und schließlich auf eine anständige Menge RAM aufgerüstet habe)

— Gert van den Berg

Antworten:

Ich habe zwei Erklärungen gefunden (von der gleichen Sache), warum ~~kswapd0 nicht~~ konstant Plattenlese geschieht auch vor OOM-Killer den säumigen Prozess tötet:

Siehe die Antwort und den Kommentar dieser askubuntu SE-Antwort
Siehe die Antwort und die Kommentare von David Schwartz zu dieser Antwort auf Unix SE

Ich zitiere hier den Kommentar von 1., der mir wirklich die Augen geöffnet hat, warum ich während des Einfrierens ständig Festplattenlesevorgänge hatte :

Stellen Sie sich zum Beispiel einen Fall vor, in dem Sie keinen Swap haben und das System fast keinen RAM mehr hat. Der Kernel bezieht Speicher von z. B. Firefox (dies ist möglich, da Firefox ausführbaren Code ausführt, der von der Festplatte geladen wurde - der Code kann bei Bedarf erneut von der Festplatte geladen werden). Wenn Firefox dann N Sekunden später erneut auf diesen Arbeitsspeicher zugreifen muss, generiert die CPU einen "harten Fehler", der Linux dazu zwingt, einen Teil des Arbeitsspeichers freizugeben (z. B. einen Teil des Arbeitsspeichers von einem anderen Prozess zu nehmen), die fehlenden Daten von der Festplatte zu laden und Firefox dann fortfahren zu lassen gewöhnlich. Dies ist ziemlich ähnlich zu normalem Tauschen und kswapd0 macht es. - Mikko Rantalainen 15. Februar um 13:08 Uhr

Wenn jemand eine Möglichkeit hat, dieses Verhalten zu deaktivieren (vielleicht den Kernel mit welchen Optionen neu kompilieren? ), Lass es mich bitte so bald wie möglich wissen! Vielen Dank!

UPDATE: Die einzige Möglichkeit , die ich bisher gefunden habe , ist durch den Kernel patchen, und es funktioniert für mich mit Swap deaktiviert (dh. , CONFIG_SWAP is not setAber nicht Arbeit für andere mit Swap aktiviert werden ) scheint ; Siehe den Patch in dieser Frage.

Bitte entfernen Sie ungültigen Text. Kennzeichnen Sie Änderungen im Text nicht mit "EDIT". Sie sind aus dem Revisionsverlauf ersichtlich .

— Kusalananda

@Kusalananda Dieser Benutzer sollte ermutigt werden, da er wahrscheinlich derjenige ist, der am meisten beigetragen hat.

— M89,

@Kusalananda Ich fand es wichtig, sie zu behalten, damit andere sehen können, was (sonst) versucht wurde und nicht funktionierte. Vielleicht wäre UPDATEstatt EDITbesser gewesen?

@MarcusLinsner Nein, sorry, du hast falsch verstanden. Zeigen , was Sie versucht haben , ist das, was Sie tun , wenn Sie fragen , eine Frage. Die Antwort sollte für die aktuell gestellte Frage richtig sein. Ich meine, eine Bearbeitung fordert den Leser sogar auf , die vorherigen Bearbeitungen zu ignorieren . Wenn Sie den Bearbeitungsverlauf anzeigen möchten, können Sie ihn hier anzeigen .

— Kusalananda

Der memory.minParameter im cgroups-v2Speichercontroller sollte helfen.

Ich zitiere nämlich:

Festplattenschutz. Wenn die Speichernutzung einer cgroup innerhalb ihrer effektiven Mindestgrenze liegt, wird der Speicher der cgroup unter keinen Umständen zurückgefordert. Wenn kein ungeschützter Speicher verfügbar ist, wird der OOM-Killer aufgerufen.

Quelle: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

— Vladimir Nikishkin
quelle

Könnten Sie bitte näher darauf eingehen? Bei der Beantwortung der OP-Frage ist Ihre Antwort etwas zu kurz.

— Paradox