Jede Linux®-Distribution enthält den Out-of-Memory (OOM) Killer-Prozess, aber was ist das? Einfach ausgedrückt ist dies der Selbsterhaltungsprozess des Servers. Um zu verstehen, was das bedeutet, sollten Sie sich überlegen, wie Linux Speicher zuweist.
Linux-Speicherzuweisung
Der Linux-Kernel weist Speicher auf Bedarfsbasis für alle Anwendungen zu, die derzeit auf dem Server ausgeführt werden. Da dies im Allgemeinen im Voraus geschieht, verwenden Anwendungen normalerweise nicht den gesamten zugewiesenen Speicher. Dadurch kann der Kernel den Speicher überlasten, wodurch der Speicher effizienter wird. Diese Überbelegung ermöglicht es dem Kernel, mehr Speicher zu belegen, als tatsächlich physisch verfügbar ist. Normalerweise ist dies kein Problem. Das Problem tritt auf, wenn zu viele Anwendungen den ihnen zugewiesenen Speicher auf einmal verwenden. Der Server läuft Gefahr abzustürzen, weil ihm der Arbeitsspeicher ausgegangen ist. Um zu verhindern, dass der Server diesen kritischen Zustand erreicht, enthält der Kernel auch einen Prozess, der als OOM Killer bekannt ist . Der Kernel verwendet diesen Prozess, um unwesentliche Prozesse zu beenden, damit der Server betriebsbereit bleibt.
Während Sie vielleicht denken, dass dies kein Problem sein sollte, verarbeiten die OOM Killerkills, die der Server als nicht wesentlich erachtet, nicht der Benutzer. Beispielsweise sind die beiden Anwendungen, die der OOM Killer normalerweise zuerst beendet, Apache® und MySQL®, da sie eine große Menge an Speicher verwenden. Jeder mit einer Website weiß sofort, dass das ein großes Problem ist. Wenn der OOM Killer einen von beiden tötet, stürzt eine Website oft sofort ab.
Warum wurde ein bestimmter Prozess beendet?
Wenn Sie herausfinden möchten, warum der OOM-Killer eine Anwendung oder einen Prozess beendet hat, können Sie nach einigen Dingen suchen, die dabei helfen können, aufzudecken, wie und warum der Prozess beendet wurde. Der erste Ort, an dem Sie nachsehen sollten, ist das syslog indem Sie den folgenden Befehl ausführen:
$ grep -i kill /var/log/messages*
host kernel: Out of Memory: Killed process 5123 (exampleprocess)
Sie sollten eine ähnliche Ausgabe wie im vorherigen Beispiel erhalten. Die Hauptstadt K ingetötet teilt Ihnen mit, dass der Prozess mit einem -9 beendet wurde Signal, und dies ist normalerweise ein guter Indikator dafür, dass der OOM-Killer schuld ist.
Zusätzlich können Sie den folgenden Befehl ausführen, um die Statistik für hohen und niedrigen Arbeitsspeicher des Servers zu überprüfen:
$ free -lh
Das -l Der Schalter zeigt hohe und niedrige Speicherstatistiken und das -h switch setzt die Ausgabe in Gigabyte um, um sie für Menschen leichter lesbar zu machen. Sie können dies in -m ändern umschalten, wenn Sie die Ausgabe in Megabyte bevorzugen. Ein zusätzlicher Vorteil dieses Befehls ist, dass er Ihnen auch Informationen zur Swap-Speichernutzung liefert. Eine Einschränkung ist, dass der free Der Befehl liefert nur eine Momentaufnahme dieses Moments, daher müssen Sie ihn mehrmals überprüfen, um eine Vorstellung davon zu bekommen, was passiert.
Glücklicherweise ist die vmstat Der Befehl erhält über einen bestimmten Zeitraum Speicherausgaben und hat sogar eine Option für eine leicht lesbare Tabelle:
$ vmstat -SM 10 20
Der vorhergehende Befehl gibt Systemspeicherinformationen zwanzig Mal in 10-Sekunden-Intervallen aus. Das bedeuten die 10 und 20 im vorigen Beispiel. Sie können diese beiden Zahlen ändern, um sie an eine Häufigkeit und Summe anzupassen, die Ihren Anforderungen besser entspricht. Das -S Schalter zeigt die Ausgabe in einem Tabellenformat an, und der -M switch zeigt die Ausgabe in Megabyte an. Verwenden Sie diesen Befehl, um anzuzeigen, was während der von Ihnen angegebenen Zeitparameter aktiv vor sich geht.
Ein weiteres gutes Werkzeug ist natürlich top Befehl. top ordnet die Ausgabe standardmäßig durch die CPU-Variable an, aber wenn Sie auf Umschalt + M klicken nach dem Ausführen von top Befehl können Sie Echtzeitaktualisierungen für die Speicherauslastung anstelle der CPU-Auslastung erhalten.
Konfiguriere den OOM-Killer
Da der OOM Killer ein Prozess ist, können Sie ihn besser an Ihre Bedürfnisse anpassen. Tatsächlich hat der OOM Killer bereits mehrere Konfigurationsoptionen eingebaut, mit denen Serveradministratoren und Entwickler auswählen können, wie sich der OOM Killer-Prozess verhalten soll, wenn sie mit einem konfrontiert werden Speicher-wird-gefährlich-niedrig-Situation. Beachten Sie, dass diese Optionen je nach Faktoren wie Umgebung und ausgeführten Anwendungen variieren können.
Wie bei allem, was mit Konfigurationsänderungen zu tun hat, ist es immer besser, vorgeschlagene Änderungen in einer Entwicklungs- oder Staging-Umgebung zu testen, bevor Sie diese Änderungen in einer Live-Produktionsumgebung vornehmen. Auf diese Weise wissen Sie, wie das System auf diese Änderungen reagiert. Schließlich sollten Sie, selbst wenn Sie sich Ihres Plans nicht sicher sind, immer eine Sicherungskopie erstellen, bevor Sie Änderungen vornehmen. Für die folgenden Konfigurationsoptionen müssen Sie der root sein Benutzer.
Option 1:Neustart
Die erste Option beinhaltet das Bearbeiten der sysctl Konfiguration (/etc/sysctl.conf ), wodurch Ihre Änderungen zwischen Neustarts bestehen bleiben:
sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
echo “vm.panic_on_oom=1” >> /etc/sysctl.conf
echo “kernel.panic=X” >> /etc/sysctl.conf
Das X im vorherigen Befehl ist die Anzahl der Sekunden, die das System warten soll, bevor es neu startet.
In den meisten Situationen ist es nicht möglich, jedes Mal neu zu starten, wenn der Arbeitsspeicher des Systems kritisch niedrig wird. Während dieser Ansatz in einigen Situationen erforderlich sein kann, ist in den meisten Fällen kein Neustart des gesamten Systems erforderlich oder gerechtfertigt, um das Problem zu beheben.
Option 2:Prozesse schützen oder opfern
Diese spezielle Option erfordert einen ausgefeilteren Ansatz. Sie können entweder (a) bestimmte Prozesse schützen, indem Sie die Wahrscheinlichkeit verringern, dass sie vom OOM-Killer getötet werden, oder (b) bestimmte Prozesse so einstellen, dass sie wahrscheinlicher getötet werden. Sie können dies mit den folgenden Befehlen erreichen:
echo -15 > /proc/(PID)/oom_adj (less likely)
echo 10 > /proc/(PID)/oom_adj (more likely)
Ersetzen Sie den (PID) Platzhalter im Beispielbefehl mit der bestimmten Prozess-ID (oder PID), an der Sie interessiert sind. Um einen Prozess zu schützen oder zu opfern, müssen Sie den übergeordneten Prozess (das Original) finden. Verwenden Sie den folgenden Befehl, um die PPID (oder übergeordnete Prozess-ID) zu finden, in der Sie den Prozess durch Ihren Prozess ersetzen (z. B. Apache, MySQL usw.):
pstree -p | grep "process" | head -1
Sie können sehen, dass diese Option etwas besser ist als die nukleare Option eines kompletten Systemneustarts. Was aber, wenn Sie einen entscheidenden Prozess haben, der nicht beendet werden kann?
Option 3:Einen Prozess ausnehmen
Diese Option ist mit einem Warnhinweis versehen. Das Freistellen von Prozessen kann unter bestimmten Umständen zu unbeabsichtigten Verhaltensänderungen führen, die weitgehend von den System- und Ressourcenkonfigurationen abhängen. Wenn der Kernel einen Prozess mit einer großen Speichermenge nicht beenden kann, beginnt er damit, andere verfügbare Prozesse zu beenden. Dies kann Prozesse umfassen, die auch wichtige Betriebssystemprozesse sein können. Das System könnte dadurch möglicherweise vollständig ausfallen. Es genügt zu sagen, verwenden Sie diese Option mit äußerster Vorsicht.
Denn der gültige Bereich für OOM Killer-Anpassungen liegt zwischen -16 und +15 , eine Einstellung von -17 nimmt einen Prozess vollständig aus, da er außerhalb des Bereichs akzeptabler Ganzzahlen für die Anpassungsskala des OOM-Killers liegt. Die allgemeine Regel lautet:Je höher der Zahlenwert, desto wahrscheinlicher wird ein Prozess ausgewählt, um getötet zu werden. Daher lautet der Befehl zum vollständigen Ausschließen eines Prozesses:
echo -17 > /proc/(PID)/oom_adj
Option 4:Die riskante Option
Warnung :Rackspace empfiehlt dies nicht für Produktionsumgebungen.
Wenn Neustarts und das Schützen, Opfern oder Freistellen von Prozessen einfach nicht gut genug sind, gibt es die letzte, riskante Option:OOM Killer vollständig deaktivieren Option.
Diese Option kann eines der folgenden Ergebnisse bewirken:
- eine ernsthafte Kernel-Panik
- ein Systemabsturz
- ein vollständiger Systemabsturz
Wieso den? Es verhindert, dass der Server sich selbst vor einem Mangel an Ressourcen bewahrt. Wenn Sie den OOM Killer vollständig deaktivieren, schützt nichts den Server davor, dass ihm der Arbeitsspeicher ausgeht. Seien Sie äußerst zurückhaltend und vorsichtig, wenn Sie diese Option in Betracht ziehen.
Um diese Option auszuüben, führen Sie den folgenden Befehl aus:
sysctl vm.overcommit_memory=2
echo “vm.overcommit_memory=2” >> /etc/sysctl.conf
Nachdem Sie nun den OOM Killer kennengelernt haben, wissen Sie, wie Sie den Prozess an Ihre individuellen Umgebungs- und Systemanforderungen anpassen können. Lassen Sie als allgemeine Regel Vorsicht walten, wenn Sie Kernelprozesse bearbeiten. Der OOM Killer ist keine Ausnahme von dieser Regel.