Vermeiden Sie das Teardown von Linux-Anwendungen mit unzureichendem Arbeitsspeicher

Lösung 1:

Standardmäßig hat Linux ein etwas hirngeschädigtes Konzept der Speicherverwaltung:Es lässt Sie mehr Speicher zuweisen, als Ihr System hat, und beendet dann willkürlich einen Prozess, wenn es in Schwierigkeiten gerät. (Die eigentliche Semantik dessen, was getötet wird, ist komplexer als das – Google „Linux OOM Killer“ für viele Details und Argumente darüber, ob es eine gute oder schlechte Sache ist).

So stellen Sie Ihrer Speicherverwaltung wieder einen Anschein von Vernunft wieder her:

1. Deaktivieren Sie den OOM-Killer (geben Sie vm.oom-kill = 0 in /etc/sysctl.conf)
2. Speicherüberlastung deaktivieren (Legen Sie vm.overcommit_memory = 2 in /etc/sysctl.conf)
   Beachten Sie, dass dies ein trinärer Wert ist:0 ="schätzen, ob wir genug RAM haben", 1 ="immer ja sagen", 2 ="nein sagen, wenn wir nicht genug Speicher haben")

Diese Einstellungen sorgen dafür, dass sich Linux auf traditionelle Weise verhält (wenn ein Prozess mehr Speicher anfordert, als verfügbar ist, schlägt malloc() fehl und der Prozess, der den Speicher anfordert, muss diesen Fehler bewältigen).

Starten Sie Ihren Computer neu, damit er /etc/sysctl.conf neu lädt , oder verwenden Sie die proc Dateisystem sofort ohne Neustart zu aktivieren:

echo 2 > /proc/sys/vm/overcommit_memory 

Lösung 2:

Sie können Overcommit deaktivieren, siehe http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Lösung 3:

Die kurze Antwort für einen Server ist, mehr RAM zu kaufen und zu installieren.

Ein Server, der regelmäßig genug Erfahrung mit OOM hat (Out-Of-Memory)-Fehler, dann ist dies neben der overcommit sysctl-Option des VM (Virtual Memory)-Managers in Linux-Kerneln keine gute Sache.

Das Erhöhen der Swap-Menge (virtueller Speicher, der vom Speichermanager des Kernels auf die Festplatte ausgelagert wurde) hilft, wenn die aktuellen Werte niedrig sind und die Nutzung viele Aufgaben mit jeweils so großen Speichermengen umfasst, anstatt nur eine oder wenige verarbeitet, die jeweils eine große Menge des gesamten verfügbaren virtuellen Speichers anfordern (RAM + Swap).

Bei vielen Anwendungen führt die Zuweisung von mehr als dem Doppelten (2x) der RAM-Menge als Auslagerung zu einem geringeren Return on Improvement. In einigen großen Computersimulationen kann dies akzeptabel sein, wenn die Geschwindigkeitsverlangsamung erträglich ist.

Mit RAM (ECC oder nicht) für bescheidene Mengen recht erschwinglich sein, z. 4-16 GB muss ich zugeben, ich habe dieses Problem schon lange nicht mehr selbst erlebt.

Die Grundlagen zur Betrachtung des Speicherverbrauchs einschließlich der Verwendung von free und top , sortiert nach Speichernutzung, als die beiden häufigsten Schnellauswertungen von Speichernutzungsmustern. Stellen Sie also sicher, dass Sie zumindest die Bedeutung jedes Felds in der Ausgabe dieser Befehle verstehen.

Da es keine Einzelheiten zu Anwendungen (z. B. Datenbank, Netzwerkdienstserver, Echtzeit-Videoverarbeitung) und der Servernutzung (wenige Power-User, 100-1000 Benutzer-/Clientverbindungen) gibt, kann ich keine allgemeinen Empfehlungen zum Umgang mit geben das OOM-Problem.

Lösung 4:

Sie können ulimit verwenden, um die Speichermenge zu reduzieren, die ein Prozess beanspruchen darf, bevor er beendet wird. Es ist sehr nützlich, wenn Ihr Problem ein oder mehrere außer Kontrolle geratene Prozesse sind, die Ihren Server zum Absturz bringen.

Wenn Ihr Problem darin besteht, dass Sie einfach nicht genug Speicher haben, um die benötigten Dienste auszuführen, gibt es nur drei Lösungen:

1. Reduzieren Sie den von Ihren Diensten verwendeten Speicher, indem Sie Caches und ähnliches begrenzen

2. Erstellen Sie einen größeren Swap-Bereich. Es kostet Sie Leistung, kann Ihnen aber etwas Zeit verschaffen.

3. Erwerben Sie mehr Arbeitsspeicher

Lösung 5:

Das Erhöhen des physischen Arbeitsspeichers ist möglicherweise nicht unter allen Umständen eine effektive Antwort.

Eine Möglichkeit, dies zu überprüfen, ist der Befehl „atop“. Besonders diese beiden Zeilen.

Dies ist ein Server, als er fehlerfrei war:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Wenn es schlecht lief (und bevor wir overcommit_memory von 50 auf 90 angepasst haben, würden wir ein Verhalten sehen, wenn vmcom weit über 50 G lief, oom-killer alle paar Sekunden Prozesse in die Luft jagte und die Last radikal abprallte, weil untergeordnete NFSd-Prozesse in die Luft gesprengt wurden ständig aktualisiert und neu erstellt.

Wir haben kürzlich Fälle dupliziert, in denen Mehrbenutzer-Linux-Terminalserver die virtuelle Speicherzuweisung massiv überlasten, aber nur sehr wenige der angeforderten Seiten tatsächlich verbraucht werden.

Obwohl es nicht ratsam ist, genau dieser Route zu folgen, haben wir den Overcommit-Speicher von den Standardwerten 50 auf 90 angepasst, was einen Teil des Problems entschärft. Am Ende mussten wir alle Benutzer auf einen anderen Terminalserver verschieben und neu starten, um den vollen Nutzen zu sehen.