Prozesse und Ressourcen: Zustände, Grenzen, Eingriffe

Die Systemlast steht bei 40, die CPUs langweilen sich — und jemand bestellt neue CPUs. Ein Prozess lässt sich nicht einmal mit dem härtesten Signal beenden. Ein Dienst ist über Nacht spurlos verschwunden, und in der Anwendung steht nichts. Alle drei Fälle haben eine Erklärung, die man auf dem Host in Minuten findet, wenn man weiß, wo sie steht. Dieses Modul zeigt dir, was die Lastzahlen wirklich zählen, warum ein Prozess unbeendbar sein kann, wie du Verbrauch je Dienst statt je Prozess misst — und wie du eine zu kleine Grenze von einem Leck unterscheidest, bevor du sie erhöhst.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-03

Ein Prozess ist selten einfach „langsam“

„Der Server ist langsam“ ist der Anfang einer Untersuchung, nicht ihr Ergebnis. Ein Prozess kann rechnen, warten, blockiert sein oder längst tot und trotzdem in der Liste stehen — und jeder dieser Zustände verlangt eine andere Reaktion.

R — laufend oder lauffähig: Der Prozess rechnet oder wartet nur darauf, an die CPU zu kommen. Viele davon heißt: CPU ist der Engpass.
S — unterbrechbar schlafend: Wartet auf etwas und lässt sich wecken. Der Normalzustand der meisten Prozesse — völlig unauffällig.
D — nicht unterbrechbar schlafend: Wartet auf Ein-/Ausgabe und ist in dieser Zeit nicht ansprechbar. Der wichtigste Zustand dieses Moduls.
Z — Zombie: Beendet, aber der Elternprozess hat das Ergebnis noch nicht abgeholt. Verbraucht keine Rechenzeit, nur einen Eintrag in der Tabelle.
T — angehalten: Durch ein Signal gestoppt und wartet auf Fortsetzung.

Warum D der interessanteste istEin Prozess im Zustand D lässt sich nicht beenden — auch nicht mit dem härtesten Signal. Er wartet im Kernel auf eine Ein-/Ausgabe, die zurückkommen muss. Wer dort mit immer härteren Signalen arbeitet, kämpft gegen die falsche Ebene: Das Problem liegt bei dem Gerät oder Netzlaufwerk, auf das gewartet wird.

Load Average misst nicht, was fast alle denken

Die drei Zahlen der Systemlast werden fast überall als „CPU-Auslastung“ gelesen. Auf Linux stimmt das nicht — und der Unterschied ist der Grund für viele Fehldiagnosen.

Load Average — Laut Dokumentation die Anzahl der Aufgaben in der Warteschlange (Zustand R) oder im Warten auf Platten-Ein-/Ausgabe (Zustand D), gemittelt über 1, 5 und 15 Minuten.

Der zweite Teil ist entscheidend. Ein Host mit einem hängenden Netzlaufwerk oder einer sterbenden Platte zeigt eine dramatische Last — bei einer CPU-Auslastung nahe null. Wer daraufhin CPUs nachrüstet, hat Geld ausgegeben und nichts verändert.

Der Zwei-Zahlen-TestHohe Last plus hohe CPU-Auslastung heißt: rechnen. Hohe Last ohne CPU-Auslastung heißt: warten — und dann ist die nächste Frage, worauf. Diese eine Unterscheidung erspart die Hälfte aller falschen Kapazitätsentscheidungen.

Und noch eine Einordnung, die oft fehlt: Die Zahl ist absolut, nicht prozentual. Eine Last von 8 ist auf einem Host mit 4 Kernen ein Problem und auf einem mit 64 Kernen unauffällig. Ohne die Kernzahl daneben ist der Wert bedeutungslos.

Signale: höflich bitten, dann bestimmt werden

Einen Prozess zu beenden ist keine einzelne Handlung, sondern eine Wahl zwischen Abstufungen. Der Unterschied liegt darin, ob das Programm noch etwas tun darf, bevor es endet.

SIGTERM: Bitte um Beendigung. Das Programm kann sie abfangen, offene Arbeiten abschließen, Dateien sauber schließen. Die Standardwahl.
SIGHUP: Ursprünglich „die Verbindung ist weg“. Viele Dienste nutzen es heute als Aufforderung, ihre Konfiguration neu einzulesen.
SIGINT: Was ein Abbruch über die Tastatur schickt. Ebenfalls abfangbar.
SIGKILL: Sofortiges Ende ohne Vorwarnung. Kann nicht abgefangen, blockiert oder ignoriert werden — und genau deshalb ist es die letzte, nicht die erste Wahl.
SIGSTOP: Anhalten. Wie SIGKILL nicht abfangbar, aber umkehrbar.

Was ein hartes Signal kostetEin Prozess, der SIGKILL bekommt, hat keine Gelegenheit mehr, irgendetwas zu Ende zu bringen: halb geschriebene Dateien bleiben halb geschrieben, Sperren bleiben liegen, Transaktionen bleiben offen. Bei einer Datenbank kann das den Start danach um Minuten verlängern oder eine Wiederherstellung nötig machen. Deshalb: erst bitten, warten, beobachten — und nur eskalieren, wenn nichts passiert.

Kurzcheck

Ein Prozess reagiert nicht auf SIGTERM. Auch SIGKILL beendet ihn nicht; in der Prozessliste steht er im Zustand D. Was folgt daraus?

Er wartet im Kernel auf eine Ein-/Ausgabe — kein Signal erreicht ihn, solange die nicht zurückkommt.
Der Prozess ignoriert das Signal, weil er es abgefangen hat und der Handler hängt.
Er ist bereits ein Zombie — beendet, aber vom Elternprozess nicht abgeholt.

Treffer. Genau. Der Zustand D ist nicht unterbrechbar; selbst das nicht abfangbare Signal wird erst zugestellt, wenn der Prozess den Kernel wieder verlässt. Die Ursache liegt bei dem Gerät oder Netzlaufwerk, auf das er wartet.

Wer verbraucht das eigentlich? Cgroups statt Prozessliste

Auf einem Host mit einem Dutzend Diensten ist „welcher Prozess verbraucht den Speicher“ die falsche Frage. Ein Dienst besteht meist aus mehreren Prozessen, und die Summe steht in keiner Prozessliste.

Cgroup — Eine Gruppe von Prozessen, deren Ressourcenverbrauch der Kernel gemeinsam zählt und begrenzt. systemd legt für jede Unit automatisch eine an — der Verbrauch je Dienst ist damit direkt ablesbar, ohne Prozesse zusammenzusuchen.

Das ist der eigentliche Fortschritt gegenüber der klassischen Prozesssicht: Die Frage „was kostet dieser Dienst“ hat eine Antwort, und die Grenze lässt sich an derselben Stelle setzen, an der gemessen wird.

memory.high: Drosselung: Über dieser Grenze werden die Prozesse gebremst und unter Rückgewinnungsdruck gesetzt. Ruft nie den OOM-Killer und kann im Extremfall überschritten werden.
memory.max: Harte Grenze. Erreicht der Verbrauch sie und lässt sich nicht senken, wird der OOM-Killer innerhalb der Cgroup aufgerufen.
cpu.max: Bandbreitengrenze in der Form „so viel Rechenzeit je Zeitfenster“.

Warum die Unterscheidung praktisch istDie weiche Grenze bremst einen Ausreißer, ohne ihn zu töten — man hat Zeit, hinzusehen. Die harte Grenze schützt den Rest des Hosts, kostet aber den Dienst. Für einen Dienst, dessen Ausfall teuer ist, setzt man deshalb oft beide: die weiche als Frühwarnung, die harte weiter oben als Notbremse.

Der OOM-Killer und wen er sich aussucht

Geht dem System oder einer Cgroup der Speicher aus, wählt der Kernel einen Prozess und beendet ihn. Das ist keine Willkür, sondern eine Bewertung — und sie lässt sich beeinflussen.

Jeder Prozess hat einen Anpassungswert im Bereich von -1000 bis +1000, der zu seiner Bewertung addiert wird. Der niedrigste Wert schaltet die Auswahl für diesen Prozess praktisch ab, weil seine Bewertung dann immer null ist; der höchste macht ihn zum bevorzugten Kandidaten.

Die Falle beim SchützenEinen Dienst vor dem OOM-Killer zu schützen klingt nach der sicheren Wahl und verschiebt nur, wer stirbt. Der Speicher ist trotzdem alle — jetzt trifft es einen anderen Prozess, möglicherweise einen, der für die Erreichbarkeit des Hosts wichtiger ist. Schutz ist eine Priorisierungsentscheidung, keine Lösung des Speicherproblems.

Wichtig für die Fehlersuche: Der OOM-Killer hinterlässt eine ausführliche Meldung im Kernel-Log — welcher Prozess, wie viel Speicher, welche Bewertung. Ein Dienst, der „einfach verschwunden“ ist, hat dort fast immer einen Eintrag. Wer ihn nicht sucht, sucht stattdessen tagelang in der Anwendung.

Grenzen pro Prozess: die andere Sorte Limit

Neben den Cgroup-Grenzen gibt es die älteren Grenzen je Prozess — die bekannteste ist die maximale Anzahl gleichzeitig geöffneter Dateien. Sie erzeugt einen der häufigsten und am meisten missverstandenen Fehler im Betrieb.

„Too many open files“ bei reichlich freiem Speicher

Szenario

Ein Proxy meldet unter Last Verbindungsfehler. Speicher und Dateisystemkapazität sind unauffällig. Das Team will das globale Limit erhöhen.

Anforderungen

Unterscheiden, ob die Dimensionierung zu klein ist oder ein Leck vorliegt
Am richtigen Ort ändern, nicht global
Die Wirkung unter Last belegen

Schritte

Die tatsächlich geltende Grenze für diesen Prozess ablesen — nicht die des eigenen Terminals. Beide unterscheiden sich fast immer.
Den aktuellen Verbrauch und seinen Verlauf ansehen: Steigt er im Betrieb kontinuierlich, ohne zurückzugehen, ist es ein Leck.
Gegenprobe: Sinkt der Verbrauch nach einem Neustart auf einen niedrigen Wert und steigt dann wieder gleichmäßig an, spricht das für ein Leck — nicht für Wachstum.
Bei einem Leck den Fehler beheben. Bei echter Dimensionierung die Grenze beim Dienst setzen, also in seiner Unit — nicht systemweit.
Unter realistischer Last prüfen, nicht im Leerlauf.

Merksatz: Eine erhöhte Grenze bei einem Leck kauft Zeit bis zum nächsten Ausfall und verlängert die Suche. Der Verlauf unterscheidet die beiden Fälle in Minuten.

Warum global die falsche Ebene istEine systemweit erhöhte Grenze gilt für alles — auch für den Dienst, dessen Leck man gerade nicht kennt. Sie nimmt dem System genau den Schutzmechanismus, der einen Ausreißer begrenzt. Die Grenze gehört dorthin, wo auch der Verbrauch entsteht.

Wer gehört zu wem: der Prozessbaum

Bei mehreren Instanzen desselben Dienstes reicht der Programmname nicht mehr aus, um zu entscheiden, wen ein Eingriff treffen soll. Zwei Sichten beantworten die Frage zuverlässig.

Prozessbaum: Wer hat wen gestartet. Zeigt, ob ein auffälliger Prozess ein Kind eines bekannten Dienstes ist oder allein dasteht.
Cgroup beziehungsweise Unit: Zu welchem Dienst der Prozess gehört. Die verlässlichere Zuordnung — sie hält auch, wenn der Elternprozess längst weg ist.

Der praktische Nutzen: Ein Eingriff lässt sich auf die betroffene Instanz begrenzen, statt alle Prozesse gleichen Namens zu treffen. Das ist der Unterschied zwischen „der eine Kundenmandant wird neu gestartet“ und „alle Mandanten sind kurz weg“.

Ein häufiges MissverständnisEin Prozess, dessen Elternprozess stirbt, verschwindet nicht mit — er wird an den ersten Prozess des Systems übergeben und läuft weiter. Wer einen Dienst über seinen Hauptprozess beendet und annimmt, damit sei alles weg, lässt regelmäßig Kinder zurück. Die Zuordnung über die Unit erfasst sie, der Prozessbaum nach dem Ende des Elternteils nicht mehr.

Speicher: welche Zahl beantwortet welche Frage

Kaum eine Kennzahl wird so oft falsch gelesen wie der freie Arbeitsspeicher. Ein Host, der „nur noch 400 MB frei“ meldet, ist meistens völlig gesund — und ein Host mit reichlich freiem Speicher kann kurz vor dem Problem stehen.

Der Grund: Linux benutzt ungenutzten Speicher als Zwischenspeicher für Dateien. Dieser Cache ist jederzeit wieder freigebbar, wird aber nicht als „frei“ gezählt. Ein Host, der lange läuft, hat deshalb fast immer wenig freien Speicher — das ist kein Mangel, sondern Nutzung.

free: Wirklich unbenutzt. Bei einem laufenden System niedrig und kein brauchbarer Indikator.
buff/cache: Von Dateien belegt und bei Bedarf freigebbar.
available: Die Schätzung, wie viel für neue Anwendungen zur Verfügung steht, ohne auszulagern — sie berücksichtigt den Cache und dass nicht alles davon zurückgewonnen werden kann. Die Zahl, auf die es ankommt.
used: Wird als Gesamt minus Verfügbar berechnet — also aus der Schätzung abgeleitet, nicht direkt gemessen.

Auch beim Prozess gibt es zwei ZahlenDer virtuelle Speicher eines Prozesses ist der Adressraum, den er angefordert hat — er kann ein Vielfaches des tatsächlich belegten betragen und sagt für sich genommen wenig. Der residente Anteil ist das, was wirklich im Arbeitsspeicher liegt. Und selbst der ist bei mehreren Instanzen irreführend, weil gemeinsam genutzte Bibliotheken bei jeder mitgezählt werden — die Summe über alle Prozesse ist deshalb größer als der tatsächliche Verbrauch.

Für die Frage „hat dieser Dienst ein Speicherproblem“ ist deshalb die Cgroup die verlässlichere Messstelle: Sie zählt genau einmal und genau das, was zu diesem Dienst gehört.

Wenn niemand mehr aufräumt

Zwei Zustände entstehen, wenn die Beziehung zwischen Eltern- und Kindprozess nicht sauber abgeschlossen wird — und beide werden regelmäßig verwechselt.

Zombie: Das Kind ist beendet, der Elternprozess hat das Ergebnis aber nie abgeholt. Verbraucht keine Rechenzeit und keinen Speicher — nur einen Eintrag in der Prozesstabelle.
Waise: Der Elternprozess ist weg, das Kind läuft weiter. Es wird an den ersten Prozess des Systems übergeben, der es später ordnungsgemäß abholt.

Warum ein Zombie kein Signal-Problem istEinen Zombie kann man nicht beenden — er ist bereits beendet. Der Fehler liegt beim Elternprozess, der seine Kinder nicht abholt. Einzelne Zombies sind harmlos; tausende weisen auf einen Programmfehler hin und können irgendwann die Prozesstabelle füllen. Die Abhilfe ist der Neustart des Elternprozesses, nicht ein Signal an das Kind.

Praktisch wird das vor allem dort, wo ein Programm als erster Prozess einer isolierten Umgebung läuft — etwa in einem Container. Dann übernimmt es die Aufräumpflicht für alle Waisen, ohne dafür gebaut zu sein, und die Zombies sammeln sich. Das ist der Grund, warum in solchen Umgebungen oft ein schlanker Startprozess davorgesetzt wird, dessen einzige Aufgabe genau dieses Abholen ist.

Swap: kein Notnagel, aber auch kein Ersatz

Auslagerungsspeicher hat einen schlechten Ruf, der zur Hälfte verdient ist. Er verhindert, dass ein einzelner Ausreißer sofort zum Beenden von Prozessen führt — und er kann ein System in einen Zustand bringen, der schlimmer ist als ein sauberer Abbruch.

Was er leistet: Selten benutzte Speicherseiten wandern auf die Platte, der Arbeitsspeicher bleibt für Aktives frei. Auf einem gesunden System völlig unauffällig.
Was er anrichtet: Bei echtem Mangel wandern aktive Seiten aus und werden sofort wieder gebraucht. Das System arbeitet dann überwiegend an sich selbst — es reagiert kaum noch, ohne dass eine einzige Grenze überschritten wäre.

Die Zahl, auf die es ankommtNicht wie viel ausgelagert ist, sondern wie viel gerade ein- und ausgelagert wird. Ein Gigabyte ausgelagerter, nie wieder gebrauchter Speicher ist harmlos. Ein dauerhafter Strom in beide Richtungen bedeutet, dass der Arbeitsspeicher nicht reicht — und dieser Zustand ist für Nutzer oft unangenehmer als ein beendeter Dienst, weil nichts abstürzt und trotzdem nichts funktioniert.

Für die Betriebsentscheidung heißt das: Auslagerung abzuschalten macht das System nicht schneller, sondern nur ehrlicher — Mangel führt dann sofort zum Beenden statt zu langsamem Siechtum. Beides ist vertretbar; die Wahl gehört bewusst getroffen und hängt daran, was für den jeweiligen Dienst schlimmer ist.

Die Reihenfolge bei einem Ressourcenproblem

Zwei Zahlen lesen: Last und CPU-Auslastung — rechnen oder warten?→Beim Warten die Zustände ansehen: viele im Zustand D deuten auf Ein-/Ausgabe→Verbrauch je Dienst über die Cgroup bestimmen, nicht je Prozess→Bei Grenzen zwischen Dimensionierung und Leck unterscheiden — über den Verlauf→Eingriff auf die betroffene Instanz begrenzen und mit dem sanftesten Signal beginnen

Der letzte Schritt verdient eine eigene Bemerkung. Ein Eingriff, der zu breit ansetzt, ist im Betrieb teurer als einer, der zu spät kommt: Wer statt einer Instanz alle acht neu startet, hat aus einem Problem für einen Kunden eines für alle gemacht — und die Ursache bleibt dabei unverändert. Die Zeit, die eine saubere Zuordnung kostet, ist fast immer kürzer als die Nachbereitung eines zu breiten Eingriffs.

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Load Average zählt auch das Warten auf Platte — hohe Last ohne CPU-Last ist ein Speicher- oder Netzproblem. Zustand D ist nicht beendbar, auch nicht hart. Der Verbrauch gehört zum Dienst, nicht zum Prozess — die Cgroup ist die richtige Messstelle. Und eine erhöhte Grenze bei einem Leck kauft nur Zeit; der Verlauf unterscheidet die Fälle.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-03