Hohe Load Average systematisch diagnostizieren

1. Was Load Average wirklich misst

Die Load Average zaehlt nicht CPU-Auslastung in Prozent, sondern die durchschnittliche Anzahl der Prozesse, die entweder auf der CPU laufen oder auf eine Ressource warten und dabei in der Runqueue des Kernels stehen. Genau dieser zweite Teil sorgt fuer Verwirrung: Ein Prozess, der auf eine langsame Festplatte wartet, zaehlt in Linux ebenso zur Load Average wie ein Prozess, der aktiv rechnet. Wer eine hohe Load Average reflexartig als CPU-Problem interpretiert, verpasst damit die Haelfte der moeglichen Ursachen.

Die drei Werte aus uptime zeigen den gleitenden Durchschnitt ueber eine, fuenf und fuenfzehn Minuten. Ein Wert von 12 auf einem Vier-Kern-Server bedeutet im Schnitt zwoelf wartende oder rechnende Prozesse gegen vier verfuegbare Kerne, also eine deutliche Ueberbuchung. Ob diese Ueberbuchung durch Rechenlast, durch Storage-Latenz oder durch blockierte Netzwerk-Aufrufe entsteht, sagt die reine Zahl jedoch nicht. Genau deshalb braucht eine systematische Diagnose mehr als einen einzigen Befehl, und genau das ist der Kern dieses Workflows fuer die Load Average.

2. Erster Blick: uptime, /proc/loadavg und vmstat

Der erste Schritt bei jeder Load Average Diagnose ist die Einordnung des Trends. uptime liefert die drei Zeitfenster auf einen Blick, /proc/loadavg liefert zusaetzlich die aktuelle Runqueue-Groesse und die Gesamtzahl der Prozesse im System als vierten und fuenften Wert. Steigt der Ein-Minuten-Wert deutlich staerker als der Fuenfzehn-Minuten-Wert, handelt es sich um eine akute Spitze. Sind alle drei Werte aehnlich hoch, liegt ein andauerndes Problem vor, das schon laenger besteht.

vmstat 2 10 zeigt zehn Messungen im Zwei-Sekunden-Abstand und trennt CPU-Zeit in us (User), sy (System), id (Idle) und wa (IO-Wait). Ein hoher wa-Wert bei gleichzeitig hoher Load Average ist der erste starke Hinweis auf IO-gebundene Wartezeiten statt echter Rechenlast. Dieser Schritt entscheidet bereits, in welche Richtung die weitere Diagnose geht, bevor ueberhaupt ein einzelner Prozess betrachtet wird.

# Step 1: quick orientation before deep-diving into any single process
uptime
# 14:32:10 up 12 days,  3:11,  2 users,  load average: 11.84, 9.02, 6.55

cat /proc/loadavg
# 11.84 9.02 6.55 14/312 28841
# fields: 1min 5min 15min running/total-processes last-pid

# Sample CPU states every 2 seconds, 10 samples
vmstat 2 10
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free  buff  cache   si   so    bi    bo   in   cs us sy id wa st
# 14  3      0 812340 98234 4213456    0    0   412  1820 3201 5920 18  6 12 64  0

In diesem Beispiel liegt wa bei 64 Prozent und id nur bei 12 Prozent, waehrend us und sy zusammen gerade einmal ein Viertel der Zeit ausmachen. Das ist ein eindeutiges Signal: Die Load Average wird hier nicht durch Rechenlast, sondern durch wartende Prozesse getrieben. Die Spalte b (blocked) bestaetigt das zusaetzlich, sie zeigt Prozesse, die auf nicht unterbrechbare Ressourcen warten und damit direkt zur Runqueue-Zahl beitragen.

3. CPU-gebunden oder IO-gebunden unterscheiden

Die Unterscheidung zwischen CPU-gebundener und IO-gebundener Load Average ist der wichtigste Fork im gesamten Diagnose-Workflow, weil beide Faelle vollstaendig unterschiedliche Loesungen erfordern. Bei CPU-gebundener Last helfen zusaetzliche Kerne, Priorisierung mit nice oder das Verschieben von Batch-Jobs auf ruhigere Zeitfenster. Bei IO-gebundener Last helfen zusaetzliche Kerne dagegen gar nichts, weil die Prozesse ohnehin nicht rechnen, sondern warten.

mpstat -P ALL 2 5 zeigt die CPU-Auslastung pro Kern statt aggregiert und deckt auf, ob nur ein einzelner Kern durch einen Single-Thread-Prozess voll ausgelastet ist, waehrend die anderen im Leerlauf stehen. Das ist ein haeufiges Muster bei PHP-FPM-Workern oder schlecht parallelisierten Batch-Skripten. Ist hingegen jeder Kern gleichmaessig ausgelastet und wa gleichzeitig hoch, deutet das auf ein systemweites Storage-Problem hin, etwa ein ueberlastetes NFS-Share oder eine langsame Cloud-Disk mit begrenztem IOPS-Kontingent.

# Per-core CPU breakdown — reveals single-core saturation
mpstat -P ALL 2 5
# 14:35:01     CPU    %usr   %sys  %iowait   %idle
# 14:35:03     all    18.20   6.10    64.30   11.40
# 14:35:03       0    72.00   4.00     2.00   22.00
# 14:35:03       1     3.10   6.80    88.10    2.00
# 14:35:03       2     2.90   7.20    87.60    2.30
# 14:35:03       3     3.30   6.20    89.50    1.00

# core 0 is CPU-bound (single-threaded process), cores 1-3 are IO-bound

Genau diese Aufschluesselung macht den Unterschied: Kern 0 rechnet tatsaechlich, die uebrigen drei Kerne warten fast ausschliesslich auf IO. Ein pauschales Fazit wie mehr CPU-Kerne kaufen wuerde in diesem Fall nur einen Bruchteil des eigentlichen Problems adressieren. Die Load Average Diagnose muss an dieser Stelle in Richtung Storage und Prozess-Zuordnung weitergehen.

4. Prozesse im D-State identifizieren

Prozesse im sogenannten D-State (uninterruptible sleep) sind der direkteste Beweis fuer IO-gebundene Load Average-Spitzen. Ein Prozess in diesem Zustand wartet auf einen Kernel-internen Vorgang, meist eine Disk- oder Netzwerk-IO-Operation, und kann in dieser Zeit nicht einmal durch ein Signal wie SIGKILL unterbrochen werden. Genau deshalb helfen viele klassische Debugging-Ansaetze hier nicht: Der Prozess reagiert schlicht nicht, weil er im Kernel und nicht im Userspace haengt.

ps -eo pid,ppid,state,wchan:32,comm --sort=-state filtert gezielt nach Zustand und zeigt zusaetzlich den Kernel-Funktionsnamen (wchan), auf den der Prozess wartet. Werte wie jbd2_journal_commit deuten auf Filesystem-Journal-Aktivitaet hin, nfs_wait_bit_killable auf ein haengendes NFS-Mount. Diese Information ist oft aussagekraeftiger als jeder generische Performance-Graph, weil sie direkt auf die Kernel-Komponente zeigt, die den Stau verursacht.

# List processes stuck in uninterruptible sleep (D state)
ps -eo pid,ppid,state,wchan:32,comm --sort=-state | awk '$3=="D"'
#   PID  PPID S WCHAN                            COMMAND
# 28841 28102 D jbd2_journal_commit             mysqld
# 29103     1 D nfs_wait_bit_killable           rsync

# Count D-state processes over time — a repeated snapshot is more useful than one
for i in $(seq 1 5); do
  echo "$(date +%T): $(ps -eo state | grep -c ^D) processes in D state"
  sleep 2
done

Zeigt die wiederholte Zaehlschleife eine stabile Anzahl von D-State-Prozessen ueber mehrere Sekunden, handelt es sich nicht um einen kurzen Ausreisser, sondern um ein anhaltendes Blockierungsproblem. In der Praxis sind das haeufig ein einzelner Prozess mit exzessivem fsync-Verhalten, ein volles Journal oder ein instabiler Netzwerk-Mount, der die Load Average fuer das gesamte System nach oben zieht.

5. pidstat und top fuer die Pro-Prozess-Zuordnung

Sobald klar ist, ob CPU oder IO die treibende Kraft der Load Average ist, muss der Workflow auf einzelne Prozesse herunterbrechen. pidstat -d 2 5 zeigt pro Prozess Lese- und Schreibraten in Kilobyte pro Sekunde sowie IO-Delay-Prozentwerte, waehrend pidstat -u 2 5 die klassische CPU-Zeit pro Prozess liefert. Der Vorteil gegenueber top ist die zeitliche Aufloesung: pidstat liefert mehrere Messpunkte hintereinander und macht damit sichtbar, ob ein Prozess dauerhaft oder nur kurzzeitig belastet.

Interaktives top mit der Taste 1 fuer die Pro-Kern-Ansicht und der Sortierung nach %CPU beziehungsweise mit htop und der Spalte fuer IO ergaenzt diese Sicht um eine schnelle visuelle Einordnung im laufenden Betrieb. Wichtig ist, in Wartungsfenstern beide Werkzeuge zu kombinieren: pidstat fuer belastbare, geloggte Zahlen und top/htop fuer die schnelle Live-Beobachtung waehrend eines akuten Vorfalls.

6. iostat: Disk-Latenz als haeufigste Ursache

In vielen Faellen ist die eigentliche Wurzel einer hohen Load Average nicht ein einzelner Prozess, sondern das darunterliegende Storage selbst. iostat -x 2 5 zeigt pro Block-Device die Warteschlangenlaenge (avgqu-sz), die durchschnittliche Wartezeit (await) und die Auslastung (%util). Ein %util nahe 100 Prozent kombiniert mit einem hohen await zeigt, dass das Storage-Geraet selbst der Flaschenhals ist, unabhaengig davon, welcher Prozess gerade darauf zugreift.

# Extended disk statistics — the storage device itself may be the bottleneck
iostat -x 2 5
# Device            r/s     w/s   rkB/s   wkB/s  await  %util
# nvme0n1          12.50  420.30  512.00 8940.10  184.20  98.70

# await of 184ms on an NVMe device is far above the expected sub-millisecond range
# — this points to a saturated underlying volume, not a specific process

Ein await-Wert von 184 Millisekunden auf einem NVMe-Geraet, das im Normalfall Werte unter einer Millisekunde liefern sollte, ist ein klares Alarmsignal. Bei Cloud-Instanzen mit gedrosselten IOPS-Kontingenten ist das ein sehr haeufiges Muster: Das Storage-Backend limitiert, nicht der Prozess. Die Konsequenz fuer die Load Average Diagnose ist, dass hier keine Anwendungsaenderung, sondern ein Storage-Upgrade oder eine IOPS-Anpassung die eigentliche Loesung ist.

7. Runqueue und Kontextwechsel mit vmstat verstehen

Die Spalte r in vmstat zeigt die Anzahl der Prozesse, die aktuell auf einen freien CPU-Kern warten, also die tatsaechliche Runqueue-Laenge. Uebersteigt dieser Wert dauerhaft die Anzahl der verfuegbaren Kerne deutlich, ist das System tatsaechlich CPU-gebunden ueberlastet, unabhaengig vom IO-Anteil. Die Spalte cs zeigt Kontextwechsel pro Sekunde: Ein ploetzlicher Anstieg deutet auf viele kurze, konkurrierende Prozesse hin, etwa durch eine PHP-FPM-Konfiguration mit zu vielen Workern fuer die vorhandene Kernzahl.

Ein haeufig uebersehener Zusammenhang bei der Load Average Analyse: Hohe Kontextwechsel-Raten kosten selbst CPU-Zeit, weil jeder Wechsel den Cache des Prozessors invalidiert. Ein System mit vielen kleinen, kurzlebigen Prozessen kann dadurch eine hoehere effektive Last erzeugen als ein System mit wenigen, laenger laufenden Prozessen, selbst bei gleicher nomineller CPU-Auslastung. Das rechtfertigt in der Praxis oft eine Reduktion der Worker-Anzahl statt einer Erhoehung.

8. Load Average in Containern und cgroups einordnen

Innerhalb eines Docker-Containers zeigt uptime traditionell die Load Average des Host-Systems an, nicht die des Containers selbst, weil der Kernel die Runqueue systemweit fuehrt. Wer also innerhalb eines Containers eine hohe Load Average sieht, misst moeglicherweise die Last anderer Container auf demselben Host mit. Das fuehrt in der Praxis regelmaessig zu Fehldiagnosen, wenn ein Team ausschliesslich innerhalb seines Containers debuggt und den Host aus dem Blick verliert.

Fuer eine korrekte Einordnung sollte die Load Average immer zusaetzlich auf dem Host gemessen werden, etwa mit docker stats fuer CPU-Prozentwerte pro Container oder mit den cgroup-eigenen Kennzahlen unter /sys/fs/cgroup/cpu.stat in cgroup v2. Der Wert nr_throttled dort zeigt, wie oft ein Container an seinem CPU-Quota-Limit gedrosselt wurde, was sich ebenfalls wie eine erhoehte Wartezeit auswirkt, obwohl der Host selbst noch freie Kapazitaet haette.

9. Symptome, Werkzeuge und Ursachen im Vergleich

Die folgende Uebersicht fasst die typischen Symptom-Kombinationen zusammen und ordnet ihnen das passende Werkzeug sowie die wahrscheinlichste Ursache zu. Sie dient als schneller Einstiegspunkt fuer den naechsten Vorfall mit hoher Load Average, ersetzt aber nicht die detaillierte Analyse aus den vorherigen Abschnitten.

Der gemeinsame Nenner aller Faelle in der Tabelle: Die reine Load Average-Zahl allein reicht fuer eine Entscheidung nie aus. Erst die Kombination aus CPU-Aufschluesselung, Prozesszustand und Storage-Metriken macht aus einem Alarm eine belastbare Diagnose, auf deren Basis man tatsaechlich handeln kann, statt teure Infrastruktur-Aenderungen ins Blaue hinein vorzunehmen.

10. Zusammenfassung

Eine hohe Load Average ist ein Symptom, kein Befund. Der beschriebene Workflow beginnt bei uptime und vmstat, um die grobe Richtung zwischen CPU- und IO-gebundener Last festzulegen, geht dann ueber mpstat zur Pro-Kern-Sicht, identifiziert mit ps und dem D-State konkrete blockierte Prozesse und bestaetigt Storage-Engpaesse mit iostat -x. Erst diese Kombination liefert eine belastbare Grundlage fuer eine Entscheidung.

Wer bei einer hohen Load Average sofort zu Infrastruktur-Upgrades greift, ohne diese Schritte durchlaufen zu haben, riskiert teure Fehlentscheidungen: zusaetzliche CPU-Kerne bei einem reinen Storage-Problem, oder ein Storage-Upgrade bei einem eigentlich falsch konfigurierten Worker-Pool. Der systematische Blick auf CPU-Zustand, Prozesszustand und Storage-Latenz spart in der Praxis nicht nur Zeit, sondern auch Budget.

11. FAQ: Load Average diagnostizieren