Jahrelang der OOM-Killer meines Betriebssystems nicht richtig funktioniert und zu einem eingefrorenen System führt.
Wenn die Speicherauslastung sehr hoch ist, neigt das gesamte System zum „Einfrieren“ (eigentlich:extrem). langsam) für Stunden oder sogar Tage , anstatt Prozesse zu beenden, um den Speicher freizugeben.
Das Maximum, das ich aufgezeichnet habe, sind 7 Tage, bevor ich mich damit abgefunden habe, einen Reset durchzuführen.
Wenn OOM kurz vor dem Erreichen des iowait steht. stark> ist sehr sehr hoch (~ 70%), bevor sie nicht mehr messbar wird.
Das Tool:iotop hat gezeigt, dass alle Programme mit einem sehr hohen Durchsatz (pro zehn MB/s) von meiner Festplatte lesen.
Was diese Programme lesen?
– Die Verzeichnishierarchie?
– Die ausführbarer Code selbst ?
Ich weiß jetzt nicht genau.
[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.
Ich hatte das gleiche Problem mit verschiedenen Linux-Distributionen und unterschiedlichen Hardwarekonfigurationen.
Aktuell (2019) verwende ich ein aktuelles Debian 9.6 (4.9.0)
Ich habe 16 GB von physischem RAM, eine SSD, auf der mein Betriebssystem installiert ist, und kein Swap Partition.
Aufgrund der Menge an RAM, die ich habe, möchte ich keine Swap-Partition aktivieren, da dies das Auftreten des Problems nur verzögern würde.
Außerdem könnte das zu häufige Austauschen von SSDs möglicherweise die Lebensdauer der Festplatte.
Übrigens habe ich es schon mit und ohne Swap-Partition versucht, es hat sich herausgestellt, dass es das Auftreten des Problems nur verzögert, aber nicht die Lösung ist.
Für mich wird das Problem dadurch verursacht, 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 nicht die ausführbaren Codepages laufender Programme 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, in der Hoffnung, dieses Problem zu beheben.
Eine davon war, /proc/sys/vm/min_free_kbytes zu setzen bis 1000000 (1 GB).
Weil dies 1 GB ist frei bleiben sollte, dachte ich, dass dieser Speicher von Linux reserviert wird, um wichtige Daten zwischenzuspeichern.
Aber es hat nicht funktioniert.
Ich denke auch, dass es nützlich ist, das hinzuzufügen, auch wenn es theoretisch großartig klingen könnte, die Größe des virtuellen Speichers auf die Größe des physischen Speichers zu beschränken, indem /proc/sys/vm/overcommit_memory definiert wird zu 2 ist in meiner Situation technisch nicht anständig möglich, da die Art von Anwendungen, die ich verwende, aus bestimmten Gründen mehr virtuellen Speicher benötigen, als sie effektiv verwenden.
Gemäß der Datei /proc/meminfo , der Commited_AS Der Wert ist oft höher als das Doppelte des physischen Arbeitsspeichers auf meinem System (16 GB, Commited_AS ist oft> 32 GB).
Ich habe dieses Problem mit /proc/sys/vm/overcommit_memory erlebt auf seinen Standardwert: , und für eine Weile habe ich es definiert als:1 , weil ich es vorgezogen habe, dass Programme vom OOM-Killer getötet werden anstatt sich falsch zu verhalten, weil sie die Rückgabewerte von malloc nicht prüfen wenn die Zuweisungen abgelehnt werden.
Als ich über dieses Problem im IRC sprach , ich habe andere Linux-Benutzer getroffen, die dasselbe Problem hatten, also denke ich, dass viele Benutzer darüber besorgt sind.
Für mich ist das nicht akzeptabel, da sogar Windows besser mit hoher Speicherauslastung umgeht.
Wenn Sie weitere Informationen benötigen, einen Vorschlag haben, sagen Sie es 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 sprechen darüber:
Warum läuft Linux Out-of-Memory (OOM) Killer nicht automatisch, sondern arbeitet mit sysrq-key?
Warum kann OOM-Killer manchmal Ressourcenfresser nicht töten?
Vorabladen des OOM-Killers
Ist es möglich, den OOM-Killer beim erzwungenen Wechseln auszulösen?
Wie vermeidet man eine hohe Latenz in der Nähe einer OOM-Situation?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843
Akzeptierte Antwort:
Ich habe zwei Erklärungen (für dasselbe) gefunden, warum kswapd0 ständiges Lesen der Festplatte passiert lange bevor der OOM-Killer den anstößigen Prozess beendet:
- 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 aus 1., der mir wirklich die Augen geöffnet hat, warum ich ständig Lesevorgänge auf der Festplatte bekam, während alles eingefroren war:
Stellen Sie sich zum Beispiel einen Fall vor, in dem Sie keinen Swap haben und dem System
fast der RAM ausgeht. Der Kernel nimmt z. B. Speicher von
Firefox (dies ist möglich, weil 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 wieder auf diesen RAM zugreifen muss, generiert die CPU einen „harten Fehler“, der Linux dazu zwingt,
etwas RAM freizugeben (z. B. etwas RAM von einem anderen Prozess zu nehmen), den
> fehlende Daten von der Festplatte und lassen Sie dann Firefox wie gewohnt weitermachen.
Dies ist dem normalen Austauschen ziemlich ähnlich und kswapd0 macht es. – Mikko
Rantalainen 15. Februar um 13:08
Wenn jemand eine Möglichkeit hat, dieses Verhalten zu deaktivieren (vielleicht den Kernel mit welchen Optionen neu kompilieren?), lassen Sie es mich bitte so schnell wie möglich wissen! Sehr geschätzt, danke!
AKTUALISIERUNG: Der einzige Weg, den ich bisher gefunden habe, ist das Patchen des Kernels, und es funktioniert für mich mit deaktiviertem Swap (d. h. CONFIG_SWAP is not set ) funktioniert aber anscheinend nicht für andere mit aktiviertem Swap; siehe Patch in dieser Frage.