Lösung 1:
Memory Overcommit kann durch vm.overcommit_memory=2 deaktiviert werden
0 ist der Standardmodus, in dem der Kernel die Zuweisung heuristisch bestimmt, indem er den freien Speicher im Vergleich zur gestellten Zuweisungsanforderung berechnet. Und wenn Sie es auf 1 setzen, wird der Zaubermodus aktiviert, in dem der Kernel immer ankündigt, dass er genügend freien Speicher für jede Zuweisung hat. Die Einstellung auf 2 bedeutet, dass Prozesse nur bis zu einer konfigurierbaren Menge (overcommit_ratio ) von RAM und erhält Zuordnungsfehler oder OOM-Meldungen, wenn diese Menge überschritten wird.
Ist es sicher, nein. Ich habe keinen richtigen Anwendungsfall gesehen, bei dem das Deaktivieren der Speicherüberbelegung tatsächlich geholfen hat, es sei denn, Sie sind sich der Arbeitslast und Hardwarekapazität zu 100% sicher. Falls Sie interessiert sind, installieren Sie kernel-docs Paket und gehen Sie zu /Documentation/sysctl/vm.txt um mehr zu lesen, oder lesen Sie es online.
Wenn Sie vm.overcommit_memory=2 einstellen dann wird es bis zu dem in vm.overcommit_ratio konfigurierten Prozentsatz des physischen RAM überschreiben (Standard ist 50 %).
echo 0/1/2 > /proc/sys/vm/overcommit_memory
Das überlebt einen Neustart nicht. Fügen Sie dies zur Persistenz in /etc/sysctl.conf ein Datei:
vm.overcommit_memory=X
und führen Sie sysctl -p aus . Kein Neustart erforderlich.
Lösung 2:
Völlig unqualifizierte Aussage:Das Deaktivieren von Memory Overcommit ist definitiv "sicherer" als es zu aktivieren.
$customer hat es auf ein paar hundert Webservern installiert und es hat sehr bei Stabilitätsproblemen geholfen. Es gibt sogar einen Nagios-Check, der wirklich laut Feuer ruft, wenn es jemals NICHT deaktiviert wird.
Auf der anderen Seite halten es die Leute vielleicht nicht für "sicher", ihre Prozesse aus dem Arbeitsspeicher zu holen, wenn sie nur ein wenig RAM überschreiben möchten und das nie wirklich nutzen würden (dh SAP wäre ein sehr gutes Beispiel)
Sie sind also wieder dabei, zu sehen, ob es die Dinge für Sie verbessert. Da Sie sich bereits damit befassen, um verwandte Probleme zu beseitigen, denke ich, dass es Ihnen helfen könnte.
(Ich weiß, dass ich eine Ablehnung durch eine mürrische Person riskiere)
Lösung 3:
Ich stimme zu, dass das Deaktivieren von Overcommit unter bestimmten Umständen sicherer ist als das Aktivieren. Wenn der Server nur wenige große Speicherjobs ausführt (wie in meinem Fall Schaltungssimulationen), ist es viel sicherer, der Anwendung die Speicheranforderung im Voraus zu verweigern, anstatt auf ein OOM-Ereignis zu warten (das sicher bald folgt). Sehr oft sehen wir Server Probleme haben, nachdem der OOM-Killer seine Arbeit erledigt hat.