Wie kann ich Speicher unter Linux ohne Overcommitting zuweisen
Das ist eine geladene Frage, oder zumindest eine falsche. Die Frage basiert auf einer falschen Annahme, wodurch die Beantwortung der gestellten Frage bestenfalls irrelevant und schlimmstenfalls irreführend wird.
Memory Overcommitment ist eine systemweite Richtlinie – da sie festlegt, wie viel virtueller Speicher Prozessen zur Verfügung gestellt wird – und nicht etwas, das ein Prozess selbst entscheiden kann.
Es ist Aufgabe des Systemadministrators zu bestimmen, ob Speicher überbelegt ist oder nicht. Unter Linux ist die Richtlinie ziemlich anpassbar (siehe z. B. /proc/sys/vm/overcommit_memory beim Mann 5 proc. Es gibt nichts, was ein Prozess während der Zuweisung tun kann, was sich auf die Speicher-Overcommit-Richtlinie auswirken würde .
OP scheint auch daran interessiert zu sein, seine Prozesse gegen den Out-of-Memory-Killer (OOM-Killer) in Linux zu immunisieren. (OOM Killer in Linux ist eine Technik, die verwendet wird, um den Speicherdruck zu verringern, indem Prozesse beendet werden und somit ihre Ressourcen wieder an das System freigegeben werden.)
Auch dies ist ein falscher Ansatz, denn der OOM-Killer ist ein heuristischer Prozess, dessen Zweck es nicht ist, "schlecht verhaltende Prozesse zu bestrafen oder zu töten", sondern das System betriebsbereit zu halten. Diese Funktion ist auch unter Linux ziemlich einstellbar, und der Systemadministrator kann sogar die Wahrscheinlichkeit einstellen, dass jeder Prozess in Situationen mit hohem Speicherdruck beendet wird. Abgesehen von der Menge an Speicher, die von einem Prozess verwendet wird, ist es nicht Sache des Prozesses, zu beeinflussen, ob der OOM-Killer ihn in Situationen mit zu wenig Speicher beendet; Auch dies ist ein Richtlinienproblem, das vom Systemadministrator verwaltet wird, und nicht von den Prozessen selbst.
Ich ging davon aus, dass die eigentliche Frage, die das OP zu lösen versucht, darin besteht, wie man Linux-Anwendungen oder -Dienste schreibt, die dynamisch auf Speicherdruck reagieren können, außer einfach zu sterben (aufgrund von SIGSEGV oder durch den OOM-Killer). Die Antwort darauf lautet:tun Sie nicht -- Sie lassen stattdessen den Systemadministrator sich darum kümmern, was ihm wichtig ist, in der Arbeitslast, die er hat -- es sei denn, Ihre Anwendung oder Ihr Dienst verwendet sehr viel Speicher und wird daher wahrscheinlich unfairerweise bei hohem Speicher beendet Druck. (Insbesondere, wenn der Datensatz groß genug ist, um eine viel größere Menge an Swaps zu aktivieren, als sonst aktiviert werden würden, was ein höheres Risiko eines Swap-Sturms und eines späten, aber zu starken OOM-Killers verursacht.)
Die Lösung oder zumindest der funktionierende Ansatz besteht darin, die kritischen Teile (oder sogar die gesamte Anwendung / den gesamten Dienst, wenn sie mit sensiblen Daten arbeitet, die nicht auf die Festplatte ausgelagert werden sollten) zu sperren oder eine Speicherzuordnung zu verwenden eine dedizierte Backing-Datei. (Für Letzteres ist hier ein Beispiel, das ich 2011 geschrieben habe und das einen Datensatz in Terabyte-Größe manipuliert.)
Der OOM-Killer kann den Prozess immer noch beenden, und es kommt immer noch zu einem SIGSEGV (z. B. aufgrund einer internen Zuweisung durch eine Bibliotheksfunktion, für die der Kernel keine RAM-Unterstützung bereitstellt), es sei denn, die gesamte Anwendung ist an RAM gebunden, aber zumindest die Dienst/Prozess ist nicht mehr unfair zielgerichtet, nur weil es viel Speicher verbraucht.
Es ist möglich, das SIGSEGV-Signal abzufangen (das auftritt, wenn kein Speicher verfügbar ist, um den virtuellen Speicher zu sichern), aber bisher habe ich keinen Anwendungsfall gesehen, der die erforderliche Codekomplexität und den erforderlichen Wartungsaufwand rechtfertigen würde.
Zusammenfassend lautet die richtige Antwort auf die gestellte Frage Nein, tun Sie das nicht .