Linux-Performance-Troubleshooting: Hohe Last und langsame Server systematisch diagnostizieren

„Der Server ist langsam“ kann vieles bedeuten: ausgelastete CPU, knapper Arbeitsspeicher, eine überlastete Festplatte, ein einzelner Prozess, der Ressourcen bindet, oder ein Netzwerkproblem. Wer mit top beginnt und auf den erstbesten hohen Wert reagiert, behandelt oft das falsche Symptom. Diese Anleitung zeigt eine feste Reihenfolge, mit der Sie den Engpass auf einem Linux-Server eingrenzen, belegen und nach einer Gegenmaßnahme erneut messen.

Voraussetzungen

• Ein Linux-Server oder eine VM, zum Beispiel Debian 12/13 oder Ubuntu 24.04/26.04, mit Shell-Zugang per SSH.
• Sudo-Rechte für einige Befehle (ss -p, Kernel-Protokoll, iotop).
• Die Pakete sysstat (enthält iostat, pidstat, sar) und optional htop und iotop: sudo apt install sysstat htop iotop.
• Keine besonderen Hardware-Anforderungen. Die Messbefehle belasten das System kaum; installieren Sie die Pakete möglichst vor dem Ernstfall, denn auf einem überlasteten Server kann schon apt lange dauern.

Schritt 1: Symptom und Zeitraum eingrenzen

Klären Sie vor jeder Messung drei Fragen: Seit wann tritt das Problem auf? Betrifft es alle Dienste oder nur einen, etwa die Website, aber nicht SSH? Ist es dauerhaft oder nur zu bestimmten Zeiten, etwa während eines nächtlichen Backups?

uptime
journalctl -b -p warning --since "1 hour ago" | tail -n 50

uptime zeigt die Laufzeit seit dem letzten Start und die Load-Mittelwerte über 1, 5 und 15 Minuten. Steigt der 1-Minuten-Wert deutlich über den 15-Minuten-Wert, nimmt die Last gerade zu. Das Journal liefert Warnungen der letzten Stunde, etwa abgestürzte Dienste oder Datenträgerfehler. Mehr dazu in Logs lesen mit journalctl und /var/log.

Verifizieren: Sie haben eine Notiz mit Beginn (Datum, Uhrzeit), betroffenem Dienst und Muster. uptime zeigt, ob der Server seit Problembeginn neu gestartet wurde.

Schritt 2: Überblick mit vmstat und PSI

vmstat zeigt CPU, Speicher, Swap und I/O in einer Zeile pro Sekunde. Die erste Zeile enthält Mittelwerte seit dem Start, aussagekräftig sind die folgenden:

nproc
vmstat 1 10

Spalte	Bedeutung laut man vmstat	Auffällig, wenn …
r	lauffähige Prozesse (laufend oder wartend auf CPU)	dauerhaft über der Kernzahl aus nproc
b	Prozesse, die auf I/O warten	über mehrere Sekunden größer 0
si/so	Speicher von/auf Swap pro Sekunde	laufend deutlich über 0
wa	CPU-Zeit mit Warten auf I/O	dauerhaft hoch bei niedrigem us
st	der VM vom Hypervisor entzogene Zeit	dauerhaft über 0 auf einem VPS

Ergänzend zeigt der Kernel mit Pressure Stall Information (PSI), welcher Anteil der Zeit Prozesse auf eine Ressource warten mussten:

cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io

Laut Kernel-Dokumentation gibt die Zeile „some“ an, wie lange mindestens ein Prozess blockiert war, „full“, wie lange alle aktiven Prozesse gleichzeitig warteten. Die Werte avg10, avg60 und avg300 sind Prozentanteile über 10, 60 und 300 Sekunden. Ein dauerhaft hoher „full“-Wert bei memory oder io bedeutet, dass das System kaum noch produktiv arbeitet.

Verifizieren: Sie können einer Ressource den höchsten Druck zuordnen: CPU (r hoch, id nahe 0), Speicher (si/so aktiv, PSI memory erhöht) oder I/O (b und wa hoch, PSI io erhöht). Fehlt /proc/pressure, ist PSI im Kernel nicht aktiv; dann genügt vmstat.

Schritt 3: CPU und Load richtig deuten

Laut man uptime ist die Load die mittlere Zahl der Prozesse, die laufen wollen oder sich in einem nicht unterbrechbaren Zustand befinden, meist beim Warten auf Datenträger. Eine Load von 8 auf einem Server mit 8 Kernen ist also Vollauslastung, auf einem Server mit 2 Kernen eine lange Warteschlange. Und eine hohe Load bei untätiger CPU weist auf I/O, nicht auf Rechenlast.

top -b -n 1 | head -n 15
mpstat -P ALL 1 3

In der Zeile %Cpu(s) von top stehen us (Anwendungen), sy (Kernel), id (untätig), wa (Warten auf I/O) und st (vom Hypervisor entzogen). mpstat aus sysstat zeigt dieselben Werte je Kern. So erkennen Sie, ob ein einzelner Thread einen Kern voll auslastet, während die übrigen frei sind. Ein hoher st-Wert auf einem VPS bedeutet, dass andere Systeme auf demselben Host die CPU beanspruchen; das lösen Sie nur über den Anbieter oder einen anderen Tarif.

Verifizieren: Echte CPU-Knappheit liegt vor, wenn id nahe 0 und us oder sy hoch sind. Ist stattdessen wa hoch und id nicht nahe 0, gehen Sie direkt zu Schritt 5.

Schritt 4: Arbeitsspeicher und Swap prüfen

free -h
sudo journalctl -k | grep -i -E "out of memory|oom-kill"

Maßgeblich ist bei free -h die Spalte available. Laut Handbuch schätzt sie, wie viel Speicher für neue Anwendungen ohne Auslagern verfügbar ist. Ein niedriger Wert in der Spalte free ist dagegen normal, weil Linux ungenutzten Speicher als Dateicache verwendet. Belegter Swap allein ist ebenfalls kein Problem; kritisch wird es, wenn si und so in vmstat laufend Bewegung zeigen.

Hat der Kernel Prozesse wegen Speichermangel beendet, steht das im Kernel-Protokoll mit Prozessname und PID.

Verifizieren: Speicherdruck liegt vor, wenn available nur noch einen kleinen Teil des Gesamtspeichers ausmacht und vmstat 1 10 über mehrere Sekunden si/so größer 0 zeigt, oder wenn das Kernel-Protokoll OOM-Einträge aus dem Problemzeitraum enthält.

Schritt 5: Datenträger und I/O prüfen

iostat -xz 1 3
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS
df -h

Auch bei iostat beschreibt der erste Bericht laut Handbuch den Zeitraum seit dem Start; werten Sie die folgenden Intervalle aus. -z blendet Geräte ohne Aktivität aus. Wichtig sind:

• r_await/w_await: mittlere Zeit in Millisekunden, bis Lese- beziehungsweise Schreibanfragen erledigt sind. Vergleichen Sie mit Werten aus ruhigen Zeiten; ein Vielfaches davon zeigt einen überlasteten Datenträger.
• aqu-sz: mittlere Länge der Warteschlange am Gerät.
• %util: Anteil der Zeit mit laufenden Anfragen. Laut Handbuch zeigt ein Wert nahe 100 % nur bei Geräten, die Anfragen nacheinander bearbeiten, eine Sättigung. Bei SSDs und RAID-Verbünden, die parallel arbeiten, sagt der Wert wenig über die Leistungsgrenze.

Prüfen Sie mit df -h außerdem den freien Platz: Ein volles Dateisystem bremst Datenbanken und Protokollierung oder bringt sie zum Stillstand.

Verifizieren: Ein I/O-Engpass ist plausibel, wenn ein Gerät über mehrere Intervalle deutlich erhöhte await-Werte und eine wachsende aqu-sz zeigt und zugleich b in vmstat größer 0 ist. Kein Dateisystem steht in df -h bei 100 %.

Schritt 6: Verursachende Prozesse und Verbindungen finden

ps aux --sort=-%cpu | head -n 10
ps aux --sort=-%mem | head -n 10
pidstat -d 1 5
sudo ss -tulpn
ss -s

Die beiden ps-Aufrufe sortieren nach CPU- beziehungsweise Speicheranteil. pidstat -d zeigt je Prozess, wie viel er liest und schreibt; alternativ listet sudo iotop -o nur Prozesse mit aktueller I/O. ss -tulpn nennt alle lauschenden Ports mit Prozess, ss -s fasst die Verbindungen nach Zustand zusammen. Ein Vielfaches der üblichen Verbindungszahl oder sehr viele Verbindungen in TIME-WAIT deuten auf hohe Last durch Clients, Bots oder eine fehlerhafte Verbindungswiederverwendung.

Gehört der auffällige Prozess zu einem systemd-Dienst, zeigt systemctl status DIENST Speicherverbrauch und die letzten Meldungen. Grenzen setzen Sie dort mit MemoryMax= oder CPUQuota=, siehe systemd-Service erstellen und verwalten.

Verifizieren: Sie können mindestens einen Prozess mit PID und zugehörigem Dienst als Verursacher benennen, oder die Listen zeigen keinen Ausreißer und der Engpass liegt außerhalb des Servers, etwa beim Hypervisor (st) oder im Netz.

Schritt 7: Ergebnisse zusammenführen und nachmessen

Formulieren Sie aus den Messungen eine Hypothese in einem Satz, zum Beispiel: „Hohe Load durch I/O-Wartezeit auf /dev/sda, verursacht vom nächtlichen Backup-Prozess.“ Typische Kombinationen:

• Hohe Load, id nahe 0, hoher us: Rechenlast, etwa zu viele Webserver-Prozesse oder eine Endlosschleife.
• Hohe Load, id hoch, b und wa hoch: Datenträger überlastet.
• si/so aktiv, PSI memory hoch, OOM-Einträge: zu wenig Arbeitsspeicher für die laufenden Dienste.
• Alle Werte unauffällig, aber Anwendung langsam: Ursache in Anwendung, Datenbankabfragen oder externen Diensten.

Ändern Sie dann genau eine Sache und messen Sie mit denselben Befehlen erneut. Für Rückblicke auf vergangene Zeiträume nutzen Sie sar aus sysstat, sofern die regelmäßige Datensammlung von sysstat eingeschaltet ist. Prüfen Sie das mit sar -u: Meldet der Befehl, dass keine Datendatei existiert, ist die Sammlung aus.

Verifizieren: Nach der Gegenmaßnahme zeigen dieselben Messungen wie vorher, etwa vmstat 1 10 oder iostat -xz 1 3, die vorher auffälligen Werte im Normalbereich, und das ursprüngliche Symptom ist verschwunden.

Typische Fehler

• Load mit CPU-Auslastung gleichgesetzt: Die Load enthält Prozesse, die auf Datenträger warten. Prüfen Sie immer id und wa mit.
• Erste Zeile von vmstat oder iostat ausgewertet: Sie zeigt Mittelwerte seit dem Start und verdeckt aktuelle Spitzen.
• Niedriger Wert bei free als Speichermangel gedeutet: Linux nutzt freien Speicher als Cache. Maßgeblich ist available.
• %util bei SSD als Sättigung gedeutet: Bei parallel arbeitenden Geräten ist der Wert wenig aussagekräftig. Schauen Sie auf await und aqu-sz.
• iostat, mpstat oder pidstat fehlen: Das Paket sysstat ist nicht installiert.
• Einzelmessung als Ursache gewertet: Werte schwanken. Messen Sie über mindestens einige Sekunden und, wenn möglich, zur Problemzeit.

Häufige Fragen

Ist hohe Load immer schlimm?

Nein. Entscheidend ist das Verhältnis zur Kernzahl und ob Prozesse arbeiten oder warten. Eine Load in Höhe der Kernzahl bei zügigen Antwortzeiten ist ein gut ausgelasteter Server.

Warum reicht ein Blick in top nicht?

Weil viele Engpässe zeitlich schwanken und top nur einen Moment zeigt. Erst mehrere Messungen über einige Sekunden und der Vergleich mit ruhigen Zeiten machen eine Ursache belastbar.

Wann hilft ein Blick in die Logs?

Immer dann, wenn Last und Fehlerbilder zusammen auftreten, etwa Datenträgerfehler, OOM-Meldungen oder Dienste, die neu starten. Mehr dazu in Logs lesen mit journalctl und /var/log.

Brauche ich ein Monitoring-System?

Für die Akutdiagnose reichen die Befehle dieser Anleitung. Um Trends zu sehen und Probleme früh zu bemerken, lohnt sich zusätzlich eine dauerhafte Aufzeichnung, mindestens mit sar.

Fazit

Linux-Performance-Troubleshooting ist vor allem eine saubere Reihenfolge: Symptom eingrenzen, mit vmstat und PSI die knappe Ressource finden, sie mit mpstat, free oder iostat vertiefen, den Verursacher mit ps, pidstat und ss benennen und nach jeder Änderung erneut messen. So vermeiden Sie Maßnahmen gegen das falsche Symptom.

Weiterführende Anleitungen und Quellen

• Logs lesen mit journalctl und /var/log
• Festplatten unter Linux einbinden
• systemd-Service erstellen und verwalten
• man uptime, man vmstat, man free, man iostat, man ss
• Kernel-Dokumentation: Pressure Stall Information (PSI)