Out-of-Memory (OOM) Event

Der Linux-Kernel überwacht fortwährend die Auslastung des Arbeitsspeichers eines Systems. Sobald die Auslastung einen kritischen Wert erreicht, kann der Kernel auf eine "out-of-memory killer" genannte Routine zurückgreifen.

Um die Stabilität des Systems nicht zu gefährden, werden durch diese Routine die zu diesem Zeitpunkt besonders arbeitsspeicherintensiven Prozesse terminiert.

Die Routine stoppt Prozesse nicht kontrolliert. Dies kann negative Folgen für die Datenintegrität haben, beispielsweise bei Datenbankdiensten.

Sollten diese "out-of-memory"-Ereignisse regelmässig auftreten, so raten wir dringend dazu, den Arbeitsspeicher zu erweitern.

Automatische Benachrichtigung

Wir informieren Sie über alle "out-of-memory"-Ereignisse, die auf Ihrem System auftreten. Für jeden Prozess (bspw. Java, MySQL, PHP) erhalten Sie eine gesonderte Information. Die Ereignisse der letzten 6 Stunden werden zusammengefasst.

Häufig betroffene Prozesse

Da der Linux-Kernel bevorzugt die besonders arbeitsspeicherintensiven Prozesse terminiert, sind bestimmte Prozesse häufiger betroffen als andere:

• MySQL
• Java
• User-Space-Prozesse, bspw. Atlassian Software
• OpenSearch / Elasticsearch
• PHP-FPM-Prozesse (Webserver-Umgebung)
• PHP-CLI-Prozesse (PHP Worker-Prozesse oder Cron Jobs)

Bitte beachten Sie, dass der Ressourcenverbrauch dieser Prozesse von der Anzahl der Zugriffe auf Ihre Webseite und der Menge der verarbeiteten Daten abhängt. In nahezu allen Fällen liegt die Ursache der „out-of-emory”-Ereignisse im Applikationsumfeld.

Linux-Speichernutzung und Anzeige der Speichernutzung

Bei der Verwendung von Tools wie (h)top oder free zur Überprüfung der Speichernutzung ist die Wahrscheinlichkeit gross, durch die angezeigten Metriken in die Irre geführt zu werden.

Diese Metriken sind:

• total: Gesamt verfügbarer Arbeitspeicher
• used: Von Diensten „direkt“ genutzter Arbeitspeicher
• free: Nicht genutzter Arbeitspeicher, ohne buff/cache
• shared: Für von Nine verwaltete Systeme meist irrelevant
• buff/cache: Von Kernel-Buffern, Datei- und Page-Caches sowie "shared memory" Segmenten genutzter Arbeitspeicher
• available: Gesamt verfügbarer Arbeitspeicher minus genutzter Arbeitspeicher

Eine häufig wenig beachtete Metrik ist „buff/cache“. Einige Dienste verwenden Arbeitsspeicher in einer Art, durch die der Kernel die Verwendung nicht in der Kategorie „used“ anzeigt. Erwähnenswerte Beispiele hierfür sind PostgreSQL und NFS. Diese Dienste verwenden fast ausschliesslich Datei- und Page-Caches. Dies kann irreführend sein, da es den Eindruck erwecken kann, dass ein System überdimensioniert ist.

Beispielhaft sehen wir auf einem unserer Kundensysteme mit 128 GB Arbeitsspeicher, auf dem PostgreSQL läuft, folgende Metriken:

root@redacted:~ # free -m
               total        used        free      shared  buff/cache   available
Mem:          128752        9823        4959       19814      113970       98170
Swap:           7811          75        7736

Die Tatsache, dass weniger als 10 GB Speicher verwendet werden, aber über 110 GB Buffer und Cache verwendet werden, zeigt, wie irreführend es sein kann, nur eine der Metriken zu betrachten.

Auf einem weiteren System, hier mit 512 GB Arbeitsspeicher, auf dem MySQL verwendet wird, sehen wir folgende Metriken:

root@redacted:~ # free -m
               total        used        free      shared  buff/cache   available
Mem:          515773      392181        7565           3      120592      123591
Swap:           8191        1714        6477

Im Gegensatz zum PostgreSQL-System findet sich der Grossteil der Speichernutzung im Bereich „used“, während der Bereich „buff/cache“ ebenfalls intensiv genutzt wird.

Der Kernel kann zwar potenziell etwas Speicher im Bereich „buff/cache“ freigeben, aber es ist wichtig zu verstehen, dass dies mit Nebenwirkungen verbunden ist, wie z. B. höheren Latenzen aufgrund von mehr Lese- und Schreibvorgängen auf der Festplatte.

Eine sinnvoll dimensionierte Umgebung sollte immer über etwas Puffer in Form von verwendetem buff/cache verfügen. Eine sehr geringe buff/cache-Verwendung und eine grosse Menge used Arbeitsspeicher, die nahe am total liegt, deutet oft auf einen Mangel an Arbeitsspeicher hin. Hier bleibt kein Raum für Wachstum und unvorhergesehene Ereignisse.

Systeme, auf die diese Beschreibung zutrifft, sind diejenigen, auf denen wir am häufigsten „out-of-memory"-Ereignisse beobachten.

Eine hohe Swap-Auslastung deutet ebenfalls auf ein Problem hin, insbesondere bei kleiner dimensionierten Umgebungen.

Dies wird in der Regel dann zum Problem, wenn die Auslastung des Swap-Bereiches ~50 % übersteigt, der used- Arbeitsspeicher fast dem total entspricht und kaum oder gar kein buffer/cache verwendet wird. Eine intensive Nutzung des Swap-Bereiches führt zu höheren Latenzen, da Inhalte des Swap-Bereiches auf die Festplatte geschrieben und von dieser gelesen werden müssen, was generell vermieden werden sollte.

Eine kleinere Menge an Swap-Nutzung im niedrigen Megabyte-Bereich ist hingegen unbedenklich. Der Kernel kann verwendeten Arbeitsspeicher in den Swap-Bereich auslagern, wenn der Algorithmus nur sehr wenig Verwendung für einen Teil des verwendeten (used) Speichers feststellt.

Wir wissen, dass es schwierig ist, Metriken im Kontext des jeweiligen Systems zu interpretieren und zu verstehen, insbesondere wenn ein System mehr als einem Zweck dient. Wir unterstützen Sie gerne bei der Analyse der Arbeitsspeichernutzung und empfehlen Ihnen eine für Ihre Anwendung und Ihr System geeignete Dimensionierung.

Arbeitsspeichernutzung durch Datenbankdienste

Datenbankdienste sind ein kritischer Teil der Anwendungsleistung. Unabhängig von der gewählten Datenbank-Engine zielen Datenbankdienste darauf ab, Festplattenzugriffe für abgefragte Daten durch die Verwendung interner Caches zu minimieren.

Datenbankentwickler empfehlen, bis zu 70 % des Arbeitsspeichers für das Caching zu reservieren. Im Idealfall sind die Caches gross genug dimensioniert, um alle Datenbankinhalte aufzunehmen. Bei einer Datenbank, deren Grösse ständig wächst, ist dies unter Umständen nicht möglich oder innerhalb eines gegebenen Budgets nicht realisierbar.

Diese Empfehlung gilt für Systeme, auf denen nur ein Datenbankdienst ausgeführt wird.

In den meisten Fällen werden auf einem System neben dem Datenbankdienst noch mehrere weitere Dienste ausgeführt, z.B. ein Webserver, eine PHP-Umgebung und ein Key-Value Store. Nine passt daher die Datenbankkonfiguration automatisch an die gewählte Systemgrösse an.

Es ist üblich, dass Datenbankdienste zwischen 40 % und 60 % des Arbeitsspeichers eines Systems belegen.

Eine hohe Speicherauslastung durch einen Datenbankdienst deutet nicht auf ein Leistungsproblem hin. Tatsächlich ist dies der gewünschte Zustand, da sich andernfalls die Leistung jeder Anwendung, die vom Datenbankdienst abhängt, erheblich verschlechtern könnte.

Aktuelle Arbeitsspeichernutzung anzeigen

Eine Übersicht der aktuellen Arbeitsspeichernutzung erhalten Sie, wenn Sie folgenden Befehl in einer Shell ausführen:

www-data@server:~ # ps -eo pid,cmd,%cpu,%mem --sort=-%mem | head -n 11

   PID CMD                         %CPU %MEM
   986 /usr/sbin/mysqld --daemoniz  0.1  7.3
125872 ruby2.5 /usr/lib/hello-worl  0.0  2.0
234301 ruby2.5 /usr/lib/find-file-  0.0  1.4
208475 ruby2.5 /usr/lib/find-dir-a  0.0  1.2
   310 ruby2.5 /usr/lib/find-dir-b  0.0  1.0
  1325 ruby2.5 /usr/lib/find-dir-c  0.0  0.9
125826 ruby2.5 /usr/lib/find-dir-d  0.0  0.9
126039 ruby2.5 /usr/lib/find-dir-e  0.1  0.9
  2089 ruby2.5 /usr/lib/find-file-  0.1  0.8
166352 ruby2.5 /usr/lib/exec-comma  0.4  0.7

Dies zeigt die 10 arbeitsspeicherintensivsten Prozesse an. Bitte beachten Sie, dass es sich dabei um eine Momentaufnahme handelt und die Arbeitsspeichernutzung - je nach Applikation oder Service - deutlichen Schwankungen unterliegt.

Zusätzlichen Arbeitsspeicher bestellen

Sollten Sie zusätzlichen Arbeitsspeicher benötigen oder Fragen zu dieser Information haben, so zögern Sie nicht, uns zu kontaktieren: