Vermeiden Sie das Herunterfahren von nicht genügend Arbeitsspeicher für Linux-Anwendungen

Ich stelle fest, dass meine Linux-Box gelegentlich keinen Speicher mehr hat und zufällige Prozesse herunterfährt, um damit umzugehen.

Ich bin neugierig, was Administratoren tun, um dies zu vermeiden? Ist die einzige echte Lösung, um die Speicherkapazität zu erhöhen (hilft allein die Erhöhung des Swap-Speichers?), Oder gibt es bessere Möglichkeiten, die Box mit Software einzurichten, um dies zu vermeiden? (dh Quoten oder einige davon?).

Standardmäßig hat Linux ein etwas hirngeschädigtes Konzept der Speicherverwaltung: Sie können mehr Speicher zuweisen als auf Ihrem System, und dann wird zufällig ein Prozess in den Kopf geschossen, wenn es Probleme gibt. (Die eigentliche Semantik dessen, was getötet wird, ist komplexer als das - Google "Linux OOM Killer" für viele Details und Argumente, ob es eine gute oder eine schlechte Sache ist).

So stellen Sie den scheinbaren Verstand Ihrer Speicherverwaltung wieder her:

1. Deaktivieren Sie den OOM Killer (Put vm.oom-kill = 0in /etc/sysctl.conf)
2. Speicherüberlastung deaktivieren ( vm.overcommit_memory = 2in /etc/sysctl.conf einfügen)
   Beachten Sie, dass dies ein trinärer Wert ist: 0 = "Schätzen Sie, ob genügend RAM vorhanden ist", 1 = "Sagen Sie immer Ja", 2 = "Sagen Sie Nein, wenn nicht." habe die Erinnerung ")

Diese Einstellungen bewirken, dass Linux sich wie gewohnt verhält (wenn ein Prozess mehr Speicher anfordert als verfügbar ist, schlägt malloc () fehl und der Prozess, der den Speicher anfordert, wird diesen Fehler voraussichtlich beheben).

Starten Sie Ihren Computer neu, um ihn neu zu laden /etc/sysctl.conf, oder verwenden Sie das procDateisystem, um ihn sofort zu aktivieren, ohne ihn neu zu starten:

echo 2 > /proc/sys/vm/overcommit_memory 

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

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

Ein Server, auf dem routinemäßig OOM -Fehler (Out-Of-Memory) aufgetreten sind. Abgesehen von der Overcommit -Option sysctl des VM-Managers in Linux-Kerneln ist dies keine gute Sache.

Das Erhöhen der Auslagerungsmenge (virtueller Speicher, der vom Speichermanager des Kernels auf die Festplatte ausgelagert wurde) hilft, wenn die aktuellen Werte niedrig sind und die Verwendung viele Aufgaben mit sich bringt, und nicht nur eine oder mehrere verarbeitet jede Anforderung einer großen Menge des gesamten verfügbaren virtuellen Speichers (RAM + Swap).

Bei vielen Anwendungen, die mehr als das Zweifache (2x) des Arbeitsspeichers als Swap zuweisen, führt dies 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 Stückzahlen durchaus bezahlbar sein, zB 4-16 GB, muss ich zugeben, ich habe dieses Problem schon lange nicht mehr selbst erlebt.

Die Grundlagen zur Betrachtung des Speicherverbrauchs umfassen die Verwendung von freeund top, sortiert nach Speichernutzung, als die beiden häufigsten schnellen Auswertungen von Speichernutzungsmustern. Vergewissern Sie sich also, dass Sie zumindest die Bedeutung der einzelnen Felder in der Ausgabe dieser Befehle verstehen.

Da keine spezifischen Anwendungen (z. B. Datenbank, Netzwerkdienstserver, Echtzeit-Videoverarbeitung) und die Servernutzung (wenige Hauptbenutzer, 100-1000 Benutzer- / Client-Verbindungen) vorliegen, kann ich mir keine allgemeinen Empfehlungen für den Umgang mit vorstellen das OOM-Problem.

Das Erhöhen des physischen Speichers ist möglicherweise nicht in allen Fällen eine wirksame Reaktion.

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

Dies ist unser 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, haben wir festgestellt, dass vmcom deutlich mehr als 50 G ausführt, dass alle paar Sekunden Eoom-Killer-Prozesse in die Luft jagen und die Last aufgrund von untergeordneten NFSd-Prozessen immer wieder radikal ansteigt up und ständig neu erstellt.

Wir haben kürzlich Fälle dupliziert, in denen Linux-Terminalserver mit mehreren Benutzern die Zuweisung des virtuellen Speichers massiv überschreiben, aber nur sehr wenige der angeforderten Seiten tatsächlich belegt werden.

Obwohl es nicht ratsam ist, genau dieser Route zu folgen, haben wir den Overcommit-Speicher von der Standardeinstellung 50 auf 90 angepasst, wodurch einige Probleme behoben wurden. Wir mussten letztendlich alle Benutzer auf einen anderen Terminalserver verschieben und neu starten, um den vollen Nutzen zu sehen.

Sie können ulimit verwenden, um die Menge an Speicher zu reduzieren, die ein Prozess beanspruchen darf, bevor er beendet wird. Es ist sehr nützlich, wenn Ihr Problem ein oder mehrere Run-Away-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 Auslagerungsbereich. Es kostet Sie Leistung, kann Ihnen aber etwas Zeit verschaffen.

3. Kaufe mehr Speicher

Ich hatte ein ähnliches Problem im Zusammenhang mit diesem Fehler und die Lösung bestand darin, einen älteren / neueren (festen) Kernel zu verwenden.

Zu der Zeit konnte ich meinen Computer jedoch nicht neu starten, so dass es eine hässliche Umgehung war, sich mit diesem Befehl als root anzumelden und System-Caches zu löschen:

echo 3 > /proc/sys/vm/drop_caches

@ voretaq7 Linux hat kein gehirngeschädigtes Konzept der Speicherverwaltung, standardmäßig ist vm.overcommit_ratio 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

Auf diese Weise schlägt Ihre Zuweisung fehl, wenn Sie über 4 GB RAM verfügen und versuchen, 4,2 GB mit malloc virtuellem Speicher zuzuweisen.

Mit vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

Mit vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage 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.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Standardmäßig überlastet Linux also nicht. Wenn Ihre Anwendung mehr Arbeitsspeicher hat als Sie, ist Ihr Code möglicherweise fehlerhaft