Ich hatte ein Problem mit einem Prozess, der aufgrund eines Fehlers sehr viele Threads erzeugte, Speicher verbrauchte und zu starkem Swapping in die Swap-Partition führte. Daher schaltete ich Swap aus – was in Serverclustern ohnehin empfohlen wird –, um das fehlerhafte Programm frühzeitig abstürzen zu lassen. Zu meiner Überraschung verbesserte dies die Situation überhaupt nicht! Ebenso vm.swappinesswenig half das Setzen auf 0. iotopergab starkes Swapping .Lektürevon der Festplatte (fast kein Schreiben).
Ich vermute, dass der Linux-Kernel immer noch Codeseiten im Speicher auslagert und überschriebene Codeseiten bei Bedarf erneut von der Festplatte liest. Wenn der RAM sehr niedrig ist, geschieht dies sehr häufig, was zu Überlastungen führt und den Computer fast nicht mehr reagieren lässt.
Wie kann man diese unglückliche und potenziell gefährliche Situation verhindern? Ich habe versucht, Swap, Cgroups für Speicher- und CPU-Beschränkungen für diesen Prozess und Ulimit für maximal 30 Prozesse auszuschalten. Nichts hat die Situation verbessert. (Nun, das ist nicht ganz richtig: Ein RAM-Limit, das Hunderte von MB dauerhaft ungenutzt ließ, hat geholfen.)
Insbesondere: Kann ich das Auslagern von Codesegmenten im Speicher verhindern und zulassen, dass der RAM-anfordernde Prozess für seinen nächsten Malloc einfach einen NULL-Wert erhält?
Antwort1
Wie wäre es, die Speicherüberlastungsberechnung anzupassen und sie auf Option 2 (keine Überlastung) statt auf die Standardoption 0 (heuristische Überlastung) einzustellen? Die Beschreibung dazu lautet
Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable amount (default is 50%) of physical RAM.
Depending on the amount you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
Der obige Ausschnitt stammt vonKernel-Dokumentation
Die Richtlinie kann mit vm.overcommitTunable festgelegt werden.