Debian 9.4, Linux 4.9
Manchmal kompiliere ich etwas, das kaum in den RAM passt, oder ein fehlerhafter Prozess fängt plötzlich an, mehr Speicher zu verbrauchen, als verfügbar ist. Wenn der Prozess den verfügbaren RAM überschreitet, beginnt Linux, die Festplatte zu überlasten, obwohl ich Zero-Swap aktiviert habe (kein Swap war ein Versuch, dies zu vermeiden). Ich schätze, es fängt an, Dinge wie die mmapPed-Teile der aktuell laufenden Binärdateien zu verwerfen und neu zu laden?
An diesem Punkt reagiert meine X-Sitzung nicht mehr und ich kann nichts anderes tun, als Dutzende von Minuten zu warten, bis die gesamte X-Sitzung beendet wird und ich mich erneut anmelden kann.
Ich habe versucht, nach Lösungen zu suchen, aber nichts scheint zu funktionieren. Der OOM-Killer erkennt diesen Prozess nicht und vm.overcommit_memory=2ich kann mich nicht einmal mit GDM und Gnome anmelden.
Gibt es einen Wegum Linux anzuweisen, überhaupt nicht zu swappen? Auf diese Weise hätte ich zumindest die Chance, dass der Rouge-Prozess durch einen fehlgeschlagenen beendet wird malloc, und selbst wenn nicht, müsste ich zumindest nicht warten, während ich auf eine nicht reagierende Maschine starre.
Oder andere Hinweise, wie man mit diesem Szenario umgehen kann?
Antwort1
Wenn Sie Quellen kompilieren, die fast den gesamten verfügbaren RAM benötigen, wenn nicht sogar mehr, ist das Hinzufügen von echtem RAM wahrscheinlich die einzige leistungsfähige Lösung. Davon abgesehen können Sie versuchen, eine sehr große Menge an Swap hinzuzufügen (sagen wir das 2- oder 3-fache des RAM) und /proc/sys/vm/swappinessauf einen niedrigen Wert wie 1 einzustellen (beachten Sie, dass bei Kernel 3.5+ das Einstellen auf 0 den Swap vollständig deaktiviert), sodass der Swap nur verwendet wird, wenn er wirklich notwendig ist. Dies sollte das Thrashing minimieren.
Antwort2
Ich verstehe nicht, wie Leute empfehlen können, mehr RAM oder Swap-Speicher hinzuzufügen. Eine fehlerhafte Anwendung kann alles aufbrauchen und das Problem reproduzieren.
Diese Art von Einfrieren ist ein schwerwiegender Architekturfehler im Linux-Kernel. Die einzige Möglichkeit, das Einfrieren wiederherzustellen, besteht darin, den OOM mit einem magischen Schlüssel (alt+sysrq+f) zu erzwingen. Das Kernel-Protokoll wird Ihnen später mitteilen, was beendet wurde und warum.
Mehrere Projekte versuchen, diese Einfrierungen im Benutzerbereich zu verhindern. Siehe beispielsweise earlyOOM.