Memory Leaks, volle Festplatten und Prozessabstürze erkennen, bevor es zum Ausfall kommt

Ein Server kann jeden Health Check bestehen und trotzdem nur noch Stunden vom Absturz entfernt sein. Ein Memory Leak, ein Out-of-Memory-Kill oder eine volllaufende Festplatte verrät sich nie durch einen einzelnen Messwert – sondern durch einen Trend, den du nur siehst, wenn du heute mit den letzten Tagen vergleichst. In diesem Beitrag erfährst du, wie du alle drei Probleme erkennst, bevor sie einen Neustart erzwingen, einen Prozess beenden oder Schreibvorgänge blockieren, und wie du die Überwachung automatisierst, damit du nicht selbst daran denken musst.

Warum sich diese Probleme zwischen den Checks verstecken

Ein Monitor, der jede Minute deine Startseite anpingt, meldet dir, dass die Website erreichbar ist – bis zu dem Moment, in dem sie es nicht mehr ist. Memory Leaks, volllaufende Festplatten und wiederholte Out-of-Memory-Kills (OOM-Kills) sind allesamt Raten-Probleme, keine Zustands-Probleme: Bei jedem einzelnen Messwert sehen sie völlig normal aus und zeigen sich erst als Steigung über Stunden oder Tage. Bis ein Dashboard rot wird, hat der Server meist schon einen Dienst neu gestartet, einen Prozess beendet oder keine Schreibvorgänge mehr angenommen.

Deshalb brauchst du für die Früherkennung einen Verlauf und nicht nur den aktuellen Wert: Du suchst nach „dieser Wert ist eine Woche lang jeden Tag gestiegen“ statt nach „dieser Wert ist gerade hoch“. Unser Leitfaden zum Lesen von Server-Metriken als Trends statt Sprünge erklärt die allgemeine Methode; dieser Beitrag wendet sie auf die drei Ausfälle an, die am häufigsten für einen Alarm um 2 Uhr nachts sorgen.

Memory Leak erkennen, bevor der Neustart kommt

Ein Memory Leak hat eine charakteristische Form: Die Speichernutzung steigt stetig, etwa um 3-5 % pro Tag, und fällt erst wieder ab, wenn der Prozess oder der Server neu startet. Wegen dieser Form kann ein Server zwischen zwei Neustarts tagelang völlig gesund aussehen – das Leck zeigt sich nur, wenn du auf die Steigung achtest, nicht auf den aktuellen Wert.

Unter Linux stellt cgroup v2 pro Control Group eine Datei memory.events mit einem oom_kill-Zähler bereit, und jeder Prozess hat einen oom_score, anhand dessen der OOM Killer des Kernels entscheidet, was er opfert, wenn der Speicher knapp wird. Ein einzelner Anstieg reicht allein nicht aus, um von einem Leck zu sprechen – eine stressige Woche kann genauso aussehen. Bestätigt wird ein Leck erst, wenn sich das Muster über mindestens zwei Neustarts wiederholt und der Speicher jedes Mal zuverlässig wieder abfällt.

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        7.1G        180M        210M        512M        420M
$ systemctl status myapp.service | grep Memory
     Memory: 6.8G (limit: 7.0G)

Wenn du myapp.service neu startest und der Speicher jedes Mal auf ein Grundniveau zurückfällt, hast du es nicht mit normaler Last zu tun – sondern mit einem Leck in genau diesem Dienst.

Wenn der OOM Killer Prozesse beendet

Wenn kein freier Speicher mehr da ist, beendet der OOM Killer des Kernels einen Prozess, um Speicher zurückzugewinnen. Was dieser Prozess gerade getan hat, bricht abrupt ab – eine Datenbankverbindung reißt, ein Queue-Job verschwindet mitten in der Ausführung –, und der Server wirkt danach oft sofort wieder in Ordnung, weil der Speicher ja gerade freigegeben wurde. Genau das macht diesen Fehler so tückisch: Er zeigt sich selten als dauerhaft hohe Speichernutzung, sondern nur als plötzlicher Abfall, gefolgt von einem Fehler an anderer Stelle in deinem Stack.

In Container-Umgebungen ist die Signatur eindeutiger: Ein so beendeter Prozess endet mit Exit-Code 137 (128 + Signal 9), und in Kubernetes lautet der Pod-Status OOMKilled. Außerhalb von Containern findest du die Aufzeichnung des Kernels in dmesg:

$ dmesg -T | grep -i 'killed process'
[Tue Oct 28 02:14:11 2025] Killed process 18422 (node) total-vm:2145728kB

Einige gängige Exit-Codes, die du bei der Analyse eines Absturzes kennen solltest:

Ein einzelner OOM-Kill kann eine einmalige Spitze sein. Drei oder mehr in einer Woche auf demselben Server sind ein Muster, das du beheben solltest – entweder gibst du dem verantwortlichen Dienst ein festes Speicherlimit, damit er vorhersehbar abstürzt, statt andere mitzureißen, oder du gibst dem Server mehr Speicher. Wenn du den Dienst mit systemd verwaltest, kombiniere das Limit mit einer sinnvollen Restart-Policy, damit ein Kill nicht zu längerer Downtime führt:

[Service]
MemoryMax=512M
Restart=on-failure
RestartSec=5s

Festplatte voll: Bytes und Inodes sind zwei verschiedene Probleme

Eine Festplatte ohne freien Speicherplatz und eine Festplatte ohne freie Inodes sehen von außen identisch aus – Schreibvorgänge schlagen mit ENOSPC fehl, „no space left on device“ –, aber df -h verrät dir nur das Erste. Jede Datei belegt unabhängig von ihrer Größe einen Inode, daher kann eine Festplatte voller kleiner Dateien (ein Cache, eine Mail-Queue, PHP-Sessions) reichlich freie Bytes melden und trotzdem komplett voll sein:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        40G   38G  1.2G  97% /
$ df -i /
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1      2621440 2621440      0  100% /

WarningEine unauffällige Ausgabe von df -h schließt eine volle Festplatte nicht aus. Prüfe immer auch df -i – sind die Inodes erschöpft, schlagen Schreibvorgänge genauso fehl wie bei fehlenden Bytes, aber eine größere Festplatte hilft dann nicht. Kleine Dateien aufzuräumen schon.

ext4-Dateisysteme reservieren außerdem standardmäßig etwa 5 % der Blöcke für root (tune2fs -m). Deshalb zeigt df -h ein Dateisystem für normale Benutzer manchmal schon als „voll“ an, kurz bevor wirklich kein Platz mehr da ist – dieser Puffer sorgt dafür, dass Systemprozesse noch etwas länger schreiben können.

So oder so ist das nützliche Signal dasselbe wie beim Speicher: Eine Festplatte, die mit konstanter Rate wächst und in einer absehbaren Anzahl von Tagen ihr Limit erreicht, ist ein Problem, das du einplanen kannst – statt eines, das dich um 3 Uhr nachts weckt.

Alle drei überwachen, ohne daran denken zu müssen

dmesg, free und df -i manuell auf jedem deiner Server auszuführen, skaliert nicht über eine Handvoll Maschinen hinaus und setzt voraus, dass jemand rechtzeitig nachschaut, bevor das Problem zuschlägt. Das Monitoring von InfraNest überwacht genau diese drei schleichenden Probleme auf jedem Server, auf dem der Agent läuft, und zeigt jedes davon auf deiner Startseite, auf der Seite des betroffenen Servers oder Volumes und in der Serverübersicht an – nicht nur versteckt in einer Logzeile.

Bei einem Leck nennt es den konkreten Dienst oder Container, dessen Speicher immer weiter wächst, sobald sich dasselbe Muster aus Anstieg und Zurücksetzen über mindestens zwei Neustarts gezeigt hat. Bei OOM-Kills markiert es einen Server, sobald in einer Woche drei oder mehr Prozesse auf diese Weise beendet wurden, und zeigt dir direkt, was den meisten Speicher belegt. Bei einem volllaufenden Volume schreibt es die aktuelle Rate fort und listet es auf, sobald es voraussichtlich innerhalb von zwei Wochen voll sein wird – bei einem Cloud-Volume direkt am Volume selbst, denn das ist es, was du tatsächlich vergrößern würdest.

Diese Prognose funktioniert nur, weil sie die letzten Tage vergleicht und nicht einen einzelnen Messwert – dasselbe Prinzip, das allgemein hinter dem Lesen von Trends statt einmaliger Sprünge bei Server-Metriken steht, und hinter einem Website- und Server-Monitoring, das tatsächlich schleichende Fehler erkennt statt nur Ausfälle.

Die Lösung: Zeit gewinnen, dann die Ursache beheben

• Memory Leak – den betroffenen Dienst nach Zeitplan neu zu starten (zum Beispiel nachts), verschafft dir Zeit, ohne den ganzen Server neu zu starten, während du die eigentliche Lösung ausrollst – oft einfach ein Update.
• Wiederholte OOM-Kills – gib dem schlimmsten Übeltäter ein festes Speicherlimit, damit er vorhersehbar abstürzt, oder rüste den Server mit mehr Speicher auf, wenn sich nichts offensichtlich falsch verhält.
• Volllaufende Festplatte – vergrößere das Volume, wenn es eine Cloud-Festplatte ist, oder räume die üblichen Verdächtigen auf (alte Logs, Backups, hängende Queues), wenn sie lokal ist.
• Volllaufende Inodes – eine größere Festplatte hilft selten; finde stattdessen den Ordner, der die meisten kleinen Dateien erzeugt, und räume ihn auf.

Nichts davon ist ein Notfall, wenn du es eine Woche vorher bemerkst. Alles davon ist ein Notfall, wenn du es erst bemerkst, wenn die Festplatte schon voll oder der Dienst schon ausgefallen ist.

Wenn du das für eine ganze Serverflotte statt für eine einzelne Maschine einrichtest, sieh dir deine Server zusammen mit ihren Monitoren an, damit ein schleichendes Leck auf einer Maschine keine separate Untersuchung neben dem Ausfall braucht, den es irgendwann verursacht.

Du willst es nicht mehr erst von einem Kunden erfahren? Richte ein Server-Monitoring ein und lass dir das Leck, das Kill-Muster und die volllaufende Festplatte melden, bevor eines davon zu Downtime führt.