CPU Load Average richtig interpretieren

1. Was Load Average wirklich misst

Die Load Average ist eine der ältesten und gleichzeitig am häufigsten missverstandenen Kennzahlen unter Linux. Sie stammt aus den frühen Unix-Systemen der 1970er Jahre und sollte ursprünglich eine einfache Frage beantworten: Wie viele Prozesse warten im Durchschnitt darauf, Rechenzeit zu bekommen. Die drei Werte in der Ausgabe von uptime, etwa 0.52 0.58 0.59, sind keine Prozentwerte und auch keine CPU-Auslastung im klassischen Sinn, sondern ein geglätteter Indikator für die Länge der Warteschlange rechenbereiter und, unter Linux zusätzlich, blockierter Prozesse.

Ein häufiger Irrtum ist die Gleichsetzung von Load Average mit CPU-Auslastung in Prozent. Eine CPU-Auslastung von 100 Prozent sagt nichts darüber aus, wie viele Prozesse zusätzlich auf Rechenzeit warten, während die Load Average genau das abbildet. Ein System kann bei niedriger CPU-Auslastung eine hohe Load Average zeigen, wenn viele Prozesse auf langsame Festplatten-I/O warten. Erst das Verständnis dieser Trennung macht die Kennzahl für die Praxis nutzbar.

2. Die drei Zahlen: exponentiell geglättete Mittelwerte

Die drei Zahlen in der Load Average stehen für Zeitfenster von einer, fünf und fünfzehn Minuten, sind aber keine einfachen arithmetischen Mittelwerte über diesen Zeitraum. Der Kernel berechnet stattdessen einen exponentiell gedämpften gleitenden Durchschnitt, bei dem jüngere Messwerte stärker gewichtet werden als ältere. Alle fünf Sekunden liest der Scheduler die aktuelle Länge der Run Queue aus und aktualisiert alle drei Werte gleichzeitig, jeweils mit einer eigenen Zeitkonstante für das jeweilige Fenster.

Die Formel lautet load(t) = load(t-5s) * exp(-5/60) + n * (1 - exp(-5/60)) für den 1-Minuten-Wert, mit exp(-5/300) für 5 Minuten und exp(-5/900) für 15 Minuten. Praktisch bedeutet das: Der 1-Minuten-Wert reagiert schnell auf kurzfristige Lastspitzen und fällt genauso schnell wieder ab, während der 15-Minuten-Wert träge ist und erst nach länger anhaltender Last deutlich steigt. Ein 1-Minuten-Wert deutlich über dem 15-Minuten-Wert zeigt eine gerade erst begonnene Lastspitze, während die umgekehrte Konstellation auf eine abklingende Spitze hindeutet.

3. Die Run Queue: was der Kernel tatsächlich zählt

Für die Berechnung zählt der Linux-Kernel zwei Kategorien von Prozessen zusammen: Prozesse im Zustand R (running oder runnable), die entweder gerade auf einer CPU laufen oder darauf warten, dass der Scheduler ihnen eine CPU zuteilt, und Prozesse im Zustand D (uninterruptible sleep), die typischerweise auf eine blockierende I/O-Operation warten, etwa das Lesen von einer Festplatte oder einem NFS-Share. Diese Kombination unterscheidet Linux von klassischem BSD-Unix, wo ursprünglich nur die eigentliche Run Queue gezählt wurde.

Genau diese Einbeziehung von D-State-Prozessen ist der Grund, warum eine hohe Load Average nicht automatisch einen CPU-Engpass bedeutet. Ein Datenbankserver, der auf ein langsames Netzwerk-Storage wartet, kann eine Load Average von 20 zeigen, obwohl die CPUs fast im Leerlauf sind. Die Zahl allein trennt diese beiden Ursachen nicht, sie signalisiert lediglich, dass Prozesse blockiert oder in der Warteschlange stehen, unabhängig vom Grund dafür.

4. Load Average ablesen: uptime, top und /proc/loadavg

Der schnellste Weg zur Load Average ist der Befehl uptime, der neben Systemlaufzeit und Anzahl angemeldeter Benutzer die drei Werte ausgibt. Dieselben Werte erscheinen in der Kopfzeile von top und htop sowie in reiner Textform unter /proc/loadavg. Diese Datei enthält fünf durch Leerzeichen getrennte Felder: die drei Load-Average-Werte, gefolgt von einem Bruch wie 2/421, der die Anzahl aktuell laufender Prozesse im Verhältnis zur Gesamtzahl aller Prozesse angibt, und abschließend die PID des zuletzt erzeugten Prozesses.

Wichtig beim Ablesen ist der Kontext: Ein einzelner Snapshot sagt wenig aus, da kurzfristige Spitzen normal sind. Aussagekräftig wird die Kennzahl erst im Trend über alle drei Zeitfenster hinweg und im Vergleich mit historischen Werten aus einem Monitoring-System wie sar oder Prometheus node_exporter. Wer regelmäßig watch -n 5 uptime laufen lässt, bekommt schnell ein Gefühl dafür, wie sich die drei Werte bei bekannten Lastmustern des eigenen Systems verhalten.

#!/usr/bin/env bash
# Read load average via three different interfaces
uptime
#  14:32:07 up 21 days,  3:47,  2 users,  load average: 0.52, 0.58, 0.59

cat /proc/loadavg
# 0.52 0.58 0.59 2/421 18273
# fields: 1min 5min 15min running/total_processes last_pid

# The same numbers appear in the top header, refreshed each interval
top -bn1 | head -1
# top - 14:32:10 up 21 days,  3:47,  2 users,  load average: 0.52, 0.58, 0.59

5. Load Average und Kernanzahl: wann wird es kritisch

Die verbreitete Faustregel lautet, dass eine Load Average unterhalb der Anzahl logischer CPU-Kerne unkritisch ist, weil im statistischen Mittel jeder rechenbereite Prozess sofort eine CPU bekommt. Auf einem System mit vier Kernen gilt eine Load Average von 4.0 demnach als voll ausgelastet, aber noch ohne Warteschlange, während ein Wert von 8.0 bedeutet, dass im Schnitt doppelt so viele Prozesse rechenbereit oder blockiert sind wie CPUs vorhanden sind.

Diese Faustregel ist ein guter Ausgangspunkt, aber kein Freibrief. Ein kurzzeitiger Anstieg des 1-Minuten-Werts über die Kernanzahl nach einem Cron-Job oder Deployment ist meist harmlos und normalisiert sich innerhalb weniger Minuten. Kritisch wird es erst, wenn der 15-Minuten-Wert dauerhaft deutlich über der Kernanzahl liegt, denn dann staut sich die Warteschlange nachweislich über längere Zeit. Auf virtualisierten Systemen kommt zusätzlich die Anzahl der tatsächlich zugeteilten vCPUs ins Spiel, nicht die im Gastsystem sichtbare nominelle Kernzahl.

groups:
  - name: load-average
    rules:
      - alert: HighLoadAveragePerCore
        # Fires only when the 15-minute average stays above core count
        expr: node_load15 / count(node_cpu_seconds_total{mode="idle"}) by (instance) > 1.5
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Load average per core sustained above 1.5 on {{ $labels.instance }}"
          description: "Check iowait and steal time before scaling capacity."

6. CPU-bound vs. I/O-bound Load unterscheiden

Die wichtigste praktische Fähigkeit im Umgang mit Load Average ist die Unterscheidung zwischen CPU-gebundener und I/O-gebundener Last, denn beide erzeugen denselben Zahlenwert, erfordern aber vollkommen unterschiedliche Maßnahmen. CPU-gebundene Last bedeutet, dass Prozesse tatsächlich Rechenzeit verbrauchen und die CPUs nahe 100 Prozent ausgelastet sind. I/O-gebundene Last bedeutet, dass Prozesse im Zustand D auf eine externe Ressource warten, während die CPUs selbst weitgehend untätig bleiben.

Der zuverlässigste Indikator zur Unterscheidung ist die %wa-Spalte (I/O wait) in top oder vmstat, die den Anteil der Zeit angibt, in dem mindestens eine CPU untätig war, weil ein ausstehender I/O-Vorgang auf Abschluss wartete. Ein hoher %wa-Wert bei gleichzeitig hoher Load Average zeigt eindeutig I/O-gebundene Last, während ein niedriger %wa-Wert mit hoher CPU-Auslastung auf echte Rechenlast hindeutet. In der Praxis hilft der Befehl ps -eo pid,stat,cmd mit Filter auf STAT D, um die konkret blockierenden Prozesse zu identifizieren.

7. Praktische Diagnose mit top, vmstat, mpstat und iostat

Nach der ersten Einordnung über uptime folgt die tiefere Diagnose mit spezialisierten Werkzeugen. top zeigt in der %Cpu(s)-Zeile die Aufschlüsselung nach us (User), sy (System), id (Idle), wa (I/O Wait) und st (Steal Time bei Virtualisierung). vmstat 1 liefert im Sekundentakt die Größe der Run Queue in der Spalte r und der blockierten Prozesse in der Spalte b, direkt neben den CPU-Prozentwerten, was eine unmittelbare Korrelation zwischen Load Average und tatsächlichem Systemverhalten erlaubt.

mpstat -P ALL 1 zeigt die Auslastung pro einzelnem CPU-Kern und deckt unausgeglichene Lastverteilung auf, etwa wenn ein einzelner Kern durch einen Single-Thread-Prozess voll ausgelastet ist, während andere Kerne im Leerlauf bleiben, die gemittelte Load Average dies aber verschleiert. iostat -xz 1 ergänzt die Sicht auf Blockgeräte-Ebene mit der Spalte %util und der durchschnittlichen Wartezeit await, die konkret zeigt, welches Gerät für die I/O-gebundene Wartezeit verantwortlich ist.

#!/usr/bin/env bash
# vmstat: run queue (r) and blocked processes (b) per second
vmstat 1 5
# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
#  6  2      0 812340  98212 4213880    0    0    12    40  980 1900 22  6 60 12  0

# mpstat: per-core utilization, exposes single-core saturation
mpstat -P ALL 1 1

# iostat: block device level wait time and utilization
iostat -xz 1 1
# Device            r/s     w/s   await  %util
# sda              4.00   12.00   38.20  87.50

8. Typische Fehlinterpretationen vermeiden

Ein häufiger Fehler ist die Annahme, ein einzelner hoher Load-Average-Wert bedeute automatisch einen Notfall. Ohne den Vergleich mit der Kernanzahl und ohne die Unterscheidung zwischen CPU- und I/O-gebundener Ursache führt das regelmäßig zu falschem Alarm oder unnötigem Hochskalieren von Ressourcen, die das eigentliche Problem gar nicht lösen. Ebenso trügerisch ist die entgegengesetzte Annahme, eine niedrige Load Average bedeute automatisch, dass keine Probleme vorliegen, denn kurze, sehr intensive CPU-Spitzen zwischen den Fünf-Sekunden-Samples werden von der exponentiellen Glättung teilweise verschluckt.

Auf Cloud-Instanzen kommt eine weitere Fehlerquelle hinzu: CPU-Steal-Time, sichtbar in der %st-Spalte von top, entsteht, wenn der Hypervisor die zugesagte CPU-Zeit wegen Konkurrenz mit anderen Mietern nicht bereitstellen kann. Eine hohe Load Average bei gleichzeitig hoher Steal-Time ist kein Problem der eigenen Anwendung, sondern ein Hinweis auf einen überbuchten Host, und keine Optimierung im eigenen Code kann das beheben. Nur eine Kombination mehrerer Kennzahlen, nie eine einzelne Zahl allein, liefert eine verlässliche Diagnose.

; /etc/sysstat/sysstat - enable historical load and CPU sampling
; so a single snapshot never has to be trusted alone
HISTORY=28
SADC_OPTIONS="-S DISK"
COMPRESSAFTER=10

; /etc/cron.d/sysstat - collect a sample every 5 minutes
; */5 * * * * root /usr/lib/sysstat/sa1 1 1

9. Load-Average-Situationen im Vergleich

In der Praxis entscheidet weniger die absolute Zahl als die richtige Einordnung des Kontexts darüber, ob eine Load Average Handlungsbedarf signalisiert. Die folgende Übersicht stellt häufige Fehlinterpretationen den korrekten Diagnoseschritten gegenüber.

Die Tabelle zeigt, dass jede Fehlinterpretation durch einen einzigen zusätzlichen Diagnosebefehl aufgelöst werden kann. Wer diese Schritte in ein Monitoring-Dashboard integriert, muss bei einer Alarmierung nicht erst manuell nachschauen, sondern sieht Load Average, I/O-Wait und Steal-Time in derselben Ansicht.

{
  "check": "cpu_load_average",
  "host": "shop-prod-02",
  "timestamp": "2026-07-12T09:15:00Z",
  "cores": 4,
  "load_1m": 3.85,
  "load_5m": 4.12,
  "load_15m": 4.30,
  "iowait_percent": 2.1,
  "steal_percent": 0.0,
  "classification": "cpu_bound",
  "status": "warning"
}

10. Zusammenfassung

Die Load Average unter Linux ist ein exponentiell geglätteter Indikator für die Anzahl rechenbereiter und blockierter Prozesse über eine, fünf und fünfzehn Minuten, keine CPU-Auslastung in Prozent. Der Kernel berechnet die drei Werte alle fünf Sekunden neu und gewichtet jüngere Messungen stärker als ältere, wodurch der 1-Minuten-Wert schnell reagiert und der 15-Minuten-Wert Trends robuster abbildet. Entscheidend für die richtige Interpretation ist der Vergleich mit der Anzahl verfügbarer CPU-Kerne sowie die Unterscheidung zwischen CPU-gebundener und I/O-gebundener Last.

In der Praxis führt kein Weg an ergänzenden Werkzeugen wie top, vmstat, mpstat und iostat vorbei, um eine hohe Load Average korrekt einzuordnen. Eine Zahl über der Kernanzahl ist ein Signal für weitere Untersuchung, kein automatischer Notfall, während eine niedrige Zahl kurze, intensive Lastspitzen verschleiern kann. Wer Load Average gemeinsam mit %wa, %st und der Verteilung über einzelne Kerne betrachtet, trifft belastbare Entscheidungen statt auf eine einzelne, leicht misszuverstehende Kennzahl zu reagieren.

11. FAQ: CPU Load Average richtig interpretieren