Ein Linux-Server reagiert träge, die Applikation hängt, oder der Load Average schnellt plötzlich hoch – aber wo genau steckt das Problem? Blindes Googlen oder zufälliges Neustarten von Diensten kostet wertvolle Zeit. Diese Anleitung zeigt dir eine methodische Diagnose-Reihenfolge auf Basis der USE-Methode (Utilization, Saturation, Errors) von Brendan Gregg: Du prüfst jede Ressource in der richtigen Reihenfolge, deutest die Ausgaben korrekt und kannst innerhalb weniger Minuten den echten Engpass – CPU, Disk-I/O, RAM oder Netzwerk – eingrenzen.

Voraussetzungen

Linux-Server mit Root- oder sudo-Zugriff (für iotop, dmesg, erweiterte pidstat-Ausgaben)
Paket sysstat installiert: enthält iostat, mpstat, sar, pidstat
Pakete htop, iotop, lsof installiert
procps-ng (enthält vmstat, top, slabtop) und iproute2 (enthält ss) – auf praktisch allen Distros vorinstalliert
Kernel ≥ 2.6.20 für iotop (CONFIG_TASK_IO_ACCOUNTING erforderlich)
Optional: sysstat-Dienst aktiviert für historische Daten: systemctl enable --now sysstat

Installation der wichtigsten Pakete:

# Debian / Ubuntu
apt install sysstat htop iotop lsof

# RHEL / CentOS / Rocky Linux
dnf install sysstat htop iotop lsof

Schritt 1: Die USE-Methode verstehen – dein Diagnose-Rahmen

Bevor du einen einzigen Befehl ausführst, lohnt es sich, das Denkmodell zu verinnerlichen. Brendan Greggs USE-Methode sagt: Prüfe jede Systemressource auf drei Dimensionen.

Dimension	Bedeutung	Typische Metrik
Utilization	Wie stark ist die Ressource ausgelastet? (%)	CPU %us, Disk %util, RAM used%
Saturation	Gibt es eine Warteschlange / müssen Prozesse warten?	vmstat r/b, iostat avgqu-sz, Swap si/so
Errors	Zählt das System Fehler?	dmesg, ip -s link (Drops), SMART-Fehler

Die Reihenfolge der Ressourcen folgt der Wahrscheinlichkeit: CPU → Disk/I/O → RAM/Swap → Netzwerk. In der Praxis löst dieser Pfad die meisten Probleme, ohne dass du tief in exotische Kernel-Strukturen eintauchen musst.

Schritt 2: Schnellüberblick in 60 Sekunden

Starte immer mit einem kompakten Systembild. Diese fünf Befehle liefern in unter einer Minute den ersten Kontext:

uptime                              # Load Average (1/5/15 Min), Betriebszeit
nproc                               # Anzahl CPU-Kerne (Referenzwert für Load)
free -h                             # RAM: total/used/available + Swap
df -h                               # Dateisystem-Füllstand
dmesg --level=err,warn | tail -20   # Kernel-Fehler und -Warnungen

Load Average deuten: Ein Wert von 8,5 auf einem 4-Kern-Server bedeutet, dass im Schnitt doppelt so viele Prozesse laufen oder warten, wie die CPU abarbeiten kann – das ist deutliche Sättigung. Aber Achtung: Load Average zählt nicht nur CPU-Prozesse, sondern auch Prozesse im D-State (uninterruptible sleep, also I/O-blockiert). Ein hoher Load bei niedriger CPU-Last zeigt fast immer ein I/O-Problem. Deshalb ist vmstat der entscheidende nächste Schritt.

Schritt 3: CPU-Analyse mit vmstat, mpstat und top

vmstat ist das wichtigste erste Diagnosewerkzeug, weil es CPU, Run-Queue und Swap in einer Ausgabe vereint:

vmstat 1 10        # Run-Queue(r), Blocked(b), iowait(wa) – alle 1 s, 10 Messungen
mpstat -P ALL 2 5  # Alle CPU-Kerne einzeln, 2-s-Intervall, 5 Messungen
top -o %CPU        # Interaktiv nach CPU sortiert; Taste '1' = Einzelkern-Ansicht
pidstat 1 5        # Prozesse mit CPU/Wait-Statistik

Wichtig: Die erste Ausgabezeile von vmstat zeigt Durchschnittswerte seit dem letzten Reboot – ignoriere sie. Erst ab der zweiten Zeile sind Echtzeit-Daten aussagekräftig.

Eine kritische vmstat-Ausgabe sieht so aus:

# r  b   swpd   free  buff  cache  si  so  bi   bo   in   cs  us sy id wa st
# 15 8  524288  2048  1024  65536  45  30  800 1200 2000 3500 10  5  5 80  0
#
# r=15, b=8  → 15 laufende, 8 blockierte Prozesse → schwere Last
# wa=80      → 80 % iowait → I/O-Bottleneck
# si=45, so=30 → aktives Swapping → RAM-Mangel

vmstat-Spalte	Bedeutung	Alarmschwelle
`r`	Run Queue: laufende + wartende CPU-Prozesse	> Anzahl CPU-Kerne = CPU-Sättigung
`b`	Blocked: Prozesse in ununterbrechbarem Sleep	> 2–3 dauerhaft = I/O-Blockade
`wa`	iowait: CPU idle, aber I/O-Requests ausstehend	> 20 % auffällig, > 40 % kritisch
`si` / `so`	Swap in / Swap out (KB/s)	Jeder Wert > 0 = aktives Swapping

Schritt 4: Disk-I/O-Analyse mit iostat und iotop

Wenn vmstat hohen iowait oder blockierte Prozesse zeigt, geht es auf Geräteebene weiter:

iostat -xz 1 10       # Erweitert: %util, await, r/s, w/s, avgqu-sz; -z=nur aktive Geräte
iostat -xzm 2 5       # Wie oben, Durchsatz in MB/s
iotop -oPa            # Nur aktive Prozesse, akkumuliert (Root erforderlich)
ps aux | awk '$8 ~ /D/'  # Alle Prozesse im D-State (I/O-blockiert)

So deutest du die iostat-Ausgabe:

# Device  tps    kB_read/s  kB_wrtn/s  %util  await  avgqu-sz
# sda     450    0.0        18000.0    98.5   45.2   12.3
#
# %util  98.5 % → Disk gesättigt (HDD)
# await  45 ms  → sehr hoch (HDD-Normal: <10 ms, >20 ms = problematisch)
# avgqu-sz 12.3 → tiefer I/O-Stau (HDD-Grenzwert: >1)

Achtung NVMe/SSD: Bei modernen SSDs und NVMe-Laufwerken kann %util nahe 100 % stehen, während await unter 1 ms bleibt – also kein echtes Problem. Hier ist await der entscheidende Indikator, nicht %util. SSD-Richtwert: < 1 ms normal, > 5 ms auffällig.

iostat-Metrik	Bedeutung	HDD-Grenzwert	SSD/NVMe-Grenzwert
`%util`	Anteil Zeit, Gerät beschäftigt	> 70 % = erhöhte Latenz	Nicht aussagekräftig (parallele Queues)
`await`	Durchschnittliche I/O-Servicezeit (ms)	< 10 ms normal, > 20 ms kritisch	< 1 ms normal, > 5 ms auffällig
`avgqu-sz`	Durchschnittliche I/O-Queue-Tiefe	> 1 = Disk überfordert	Bis 32 noch normal

Schritt 5: RAM und Swap analysieren

Einer der häufigsten Denkfehler: „free zeigt nur 200 MB – der RAM ist voll!" Auf Linux ist das normal, denn der Kernel nutzt freien RAM als Page-Cache. Der entscheidende Wert ist available, nicht free.

free -h                           # available-Spalte entscheidend, nicht free
vmstat 1 10                       # si/so-Spalten: Swap in/out > 0 = RAM-Problem
dmesg | grep -i oom               # OOM-Killer-Ereignisse
ps aux --sort=-%mem | head -15    # Top-RAM-Verbraucher
slabtop -s c                      # Kernel-Slab-Cache nach Cache-Größe sortiert

Echter RAM-Mangel liegt vor, wenn available < 5–10 % des Gesamt-RAM UND si/so in vmstat dauerhaft > 0 sind. Werte von 100+ MB/s bedeuten einen Swap-Storm – sofortiger Handlungsbedarf. Auch wenn si/so bereits wieder 0 sind, solltest du immer noch dmesg | grep -i oom prüfen: Wenn der OOM-Killer bereits Prozesse beendet hat, ist der Schaden womöglich schon geschehen.

Schritt 6: Netzwerk und Sockets mit ss analysieren

ss ist der moderne Ersatz für netstat und liefert Socket-Statistiken deutlich schneller:

ss -s                              # Zusammenfassung: TCP estab/timewait/closedwait
ss -tp state established           # Alle etablierten TCP-Verbindungen mit PID
ss -Htn state time-wait | wc -l    # Anzahl TIME_WAIT-Verbindungen zählen
ss -tn state close-wait            # CLOSE_WAIT = potenzieller App-Bug
sar -n DEV 2 5                     # Netzwerk-Durchsatz pro Interface
ip -s link show                    # Fehler und Drops pro Interface

Viele TIME_WAIT-Verbindungen (Tausende) sind kein Fehler, sondern ein Hinweis auf viele kurzlebige TCP-Verbindungen. Lösung: Connection Pooling in der Applikation aktivieren, HTTP Keep-Alive nutzen. Persistente CLOSE_WAIT-Verbindungen hingegen weisen fast immer auf einen Applikationsfehler hin – der Code schließt den Socket nach Remote-Close nicht. Ein Dienstneustart behebt das temporär, aber nur ein Code-Fix löst die Ursache dauerhaft.

Schritt 7: Drei Fallbeispiele mit konkreten Diagnose-Pfaden

Fallbeispiel 1: Langsame Datenbank (I/O-Bottleneck)

# 1. vmstat 1 5     → wa hoch, b > 0?
vmstat 1 5

# 2. iostat -xz 1 5 → %util nahe 100 %, await > 50 ms?
iostat -xz 1 5

# 3. iotop -oPa     → DB-Prozess (mysqld/postgres) vorne?
iotop -oPa

# 4. lsof -p <PID>  → welche Dateien werden geöffnet?
lsof -p <PID>

Typischer Befund: iostat zeigt %util > 90 % und await > 50 ms auf der Datenbankpartition, iotop identifiziert mysqld als größten I/O-Erzeuger. Mögliche Maßnahmen: Query-Optimierung, Index setzen, Daten auf schnellere Disk migrieren oder Datenbankpuffer (innodb_buffer_pool_size) erhöhen.

Fallbeispiel 2: Vollgelaufener RAM mit Swap-Storm

# 1. free -h            → available < 5 % des Gesamt-RAM?
free -h

# 2. vmstat 1 5         → si/so dauerhaft > 0?
vmstat 1 5

# 3. dmesg | grep oom   → OOM-Killer aktiv?
dmesg | grep -i oom

# 4. ps aux --sort=-%mem | head -10  → Wer verbraucht RAM?
ps aux --sort=-%mem | head -10

Fallbeispiel 3: Backup blockiert den restlichen I/O

# 1. iotop -oPa         → Backup-Prozess (rsync/tar/dd) dominiert?
iotop -oPa

# 2. I/O-Priorität des Backups auf Idle setzen (sofort wirksam):
ionice -c 3 -p <PID>

# Oder Backup direkt mit niedriger I/O- und CPU-Priorität starten:
ionice -c 3 nice -n 19 rsync -av /data /backup

Schritt 8: Historische Daten mit sar auswerten

Wenn das Problem intermittierend auftritt oder bereits abgeklungen ist, liefert sar (Teil von sysstat) historische Daten – vorausgesetzt, der sysstat-Dienst war aktiv:

sar -u          # CPU-Verlauf des heutigen Tages
sar -r          # RAM-Verlauf
sar -d          # Disk-I/O-Verlauf
sar -q          # Load-Average-Verlauf
sar -n DEV      # Netzwerk-Verlauf

# Für einen bestimmten Tag (z. B. Tag 15):
sar -u -f /var/log/sa/sa15

Falls keine Daten vorhanden sind: systemctl status sysstat prüfen. Auf frischen Systemen ist der sysstat-Dienst oft nicht aktiviert. Aktivieren mit: systemctl enable --now sysstat.

Troubleshooting / Typische Fehler

Load Average hoch, CPU idle: Häufigster Denkfehler. Load Average zählt auch D-State-Prozesse (I/O-blockiert). Lösung: vmstat 1 prüfen – ist wa hoch und b > 0? Dann ist Disk/NFS der Engpass, nicht CPU. D-State-Prozesse finden: ps aux | awk '$8 ~ /D/'
free zeigt 0 – Panik unbegründet: Linux nutzt ungenutzten RAM als Page-Cache. Der relevante Wert ist available in der free -h-Ausgabe, nicht free. Erst wenn available < 5 % und si/so > 0, liegt echter RAM-Mangel vor.
iostat %util 100 % auf NVMe/SSD – kein echtes Problem: Moderne SSDs bedienen parallele I/O-Queues. %util kann nahe 100 % stehen, während await < 1 ms bleibt. Immer await als entscheidenden Indikator heranziehen.
iotop: „Netlink error" oder Berechtigungsfehler: iotop benötigt Root-Rechte (CAP_NET_ADMIN). Auf älteren Kerneln fehlt möglicherweise CONFIG_TASK_IO_ACCOUNTING. Alternative: pidstat -d 1.
CLOSE_WAIT-Verbindungen verschwinden nicht: Persistente CLOSE_WAIT-Verbindungen zeigen, dass die Applikation den Socket nach Remote-Close nicht schließt. Neustart des Dienstes behebt das temporär – die eigentliche Lösung ist ein Code-Fix.
sar liefert keine historischen Daten: sysstat-Dienst ist deaktiviert. Aktivieren: systemctl enable --now sysstat. Daten liegen danach in /var/log/sa/.
vmstat erste Zeile ignorieren: Die erste Ausgabezeile von vmstat enthält Durchschnittswerte seit dem letzten Reboot, keine Echtzeit-Daten. Erst ab der zweiten Zeile sind die Werte aussagekräftig.
Hohe %sy (System-CPU) ohne klaren Prozess: Kann auf Kernel-Treiber-Probleme oder Interrupt-Storms hinweisen. Prüfen mit: cat /proc/interrupts | sort -k2 -rn | head -20 sowie sar -I ALL 1 5.

Häufige Fragen

Wie interpretiere ich Load Average 8,5 auf einem 4-Kern-Server?

Load Average 8,5 bei 4 Kernen bedeutet, dass im Schnitt doppelt so viele Prozesse laufen oder warten, wie die CPU abarbeiten kann – das ist deutliche Sättigung. Nächster Schritt: vmstat 1 prüfen. Ist die r-Spalte > 4 und wa niedrig? Dann CPU-bound. Ist wa > 20 % und die b-Spalte hoch? Dann I/O-bound.

Was ist der Unterschied zwischen %iowait und %util?

%iowait (in top/vmstat als wa) ist eine CPU-Metrik: Anteil der Zeit, in der die CPU idle war und auf I/O wartete. %util (iostat) ist eine Disk-Metrik: Anteil der Zeit, in der das Gerät mit mindestens einem Request beschäftigt war. Beide können unabhängig voneinander hoch oder niedrig sein – ein System mit schnellen SSDs kann kaum iowait zeigen, obwohl die Disks voll ausgelastet sind.

Wann soll ich iotop statt iostat einsetzen?

iostat zeigt die Geräteebene (welche Disk ist ausgelastet), iotop zeigt die Prozessebene (welcher Prozess verursacht die Last). Die typische Reihenfolge: iostat erkennt den Engpass, iotop identifiziert den Verursacher.

Mein Server hat 32 GB RAM, free -h zeigt aber nur 200 MB free – ist das ein Problem?

Nein, das ist normales Linux-Verhalten. Der Kernel füllt ungenutzten RAM mit Page-Cache auf. Der entscheidende Wert ist available in der free-Ausgabe. Erst wenn available < 5–10 % des Gesamt-RAM und si/so in vmstat > 0 sind, liegt echter RAM-Mangel vor.

Wie finde ich schnell heraus, welcher Prozess D-State verursacht?

Befehl: ps aux | awk '$8 ~ /D/' zeigt alle Prozesse im ununterbrechbaren Sleep. Alternativ in htop: F4 drücken und „D" eingeben. Dann mit lsof -p <PID> prüfen, auf welche Datei oder welches Gerät gewartet wird.

Was tun bei Tausenden von TIME_WAIT-Verbindungen?

TIME_WAIT ist kein Fehler, sondern ein normaler TCP-Zustand nach dem Verbindungsabbau (wartet 60 Sekunden). Viele TIME_WAIT-Verbindungen bedeuten viele kurzlebige Verbindungen. Empfehlung: Connection Pooling in der Applikation aktivieren, HTTP Keep-Alive nutzen. Als letzte Option lassen sich net.ipv4.tcp_fin_timeout und net.ipv4.tcp_tw_reuse anpassen – aber nur nach sorgfältiger Prüfung der Auswirkungen.

Fazit

Linux-Performance-Troubleshooting ist keine Zauberei – es ist eine methodische Abfolge von Fragen an das System. Mit der USE-Methode als Rahmen, vmstat als erstem Diagnoseschritt und iostat, iotop sowie ss als spezialisierten Werkzeugen kannst du die meisten Engpässe innerhalb weniger Minuten eingrenzen. Der wichtigste Grundsatz dabei: Load Average allein lügt – erst die Kombination aus iowait, Run-Queue, Disk-Sättigung und Swap-Aktivität führt zuverlässig von Symptomen zu Ursachen. Drucke dir den Spickzettel mit den vmstat- und iostat-Interpretationswerten aus und hänge ihn an deinen Monitor – das nächste Notfall-Szenario kommt bestimmt.

Weiterführende Anleitungen und Quellen

Linux-Logs lesen mit journalctl und /var/log – Systemlogs und Kernel-Meldungen verstehen
Linux-Server absichern mit UFW und Fail2ban – Netzwerkabsicherung nach der Performance-Diagnose
Festplatten, Partitionen, LVM und fstab unter Linux – Disk-Probleme strukturell lösen
Systemd-Services erstellen und verwalten – Dienste nach der Fehleranalyse korrekt konfigurieren

Quellen: Brendan Gregg, USE Method – Linux Performance Checklist (brendangregg.com); Brendan Gregg, Linux Performance Overview (brendangregg.com); Netdata Academy, Linux Load Average Spikes and IOWait Bottlenecks; man7.org, ss(8) Linux Manual Page; Site24x7 Learn, Understanding and Troubleshooting High IOWait in Linux.