Monitoring & Betrieb

Linux-Server langsam? So findest du die Ursache systematisch

Rate nicht an Stellschrauben, sondern miss in einer Reihenfolge: CPU, Speicher, I/O, Netz. In den meisten Fällen ist es I/O-Wait oder ein Prozess, der Speicher frisst, und beides siehst du in wenigen Minuten mit Bordmitteln.

6 Kapitel mit allen Befehlen
Betriebsingenieur beobachtet mehrere Monitoring-Bildschirme im Leitstand
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Ursachensuche so oft im Kreis läuft

Der typische Fall sieht zunächst harmlos aus: Das Ticket meldet einen langsamen Server, uptime zeigt eine Load von 24 bei 8 Kernen, und in top steht die CPU trotzdem bei über 80 Prozent idle. Genau hier beginnt das Missverständnis. Der Load Average unter Linux zählt nicht nur laufende Prozesse, sondern auch solche im unterbrechungsfreien Schlaf im Status D, also Prozesse, die auf Block-I/O oder ein hängendes NFS-Mount warten. Eine hohe Load bei niedriger CPU-Auslastung deutet deshalb fast immer auf Storage oder Netzwerk hin, nicht auf zu wenig Rechenleistung.

Unter Druck wird dann häufig an der falschen Stelle gedreht. Es kommen vCPUs oder RAM dazu, Dienste werden reihum neu gestartet, der Swap wird abgeschaltet oder vm.swappiness auf 0 gesetzt, ohne dass jemand geprüft hat, ob überhaupt aktiv ausgelagert wird. Ein hoher Wert bei used swap sagt für sich genommen wenig aus, entscheidend sind die Raten si und so in vmstat. Ebenso wenig ist ein kleiner Wert bei free ein Problem, solange Page Cache und Buffers den Großteil belegen und available ausreichend groß bleibt.

Das zweite Muster ist die fehlende Referenz. Ohne Daten aus dem Normalbetrieb lässt sich nicht beurteilen, ob 40 Prozent iowait, mehrere tausend Kontextwechsel pro Sekunde oder eine wachsende Recv-Q an einem Socket für dieses System auffällig sind. Wer erst im Störfall anfängt zu messen, sieht nur eine Momentaufnahme und diskutiert anschließend über Vermutungen. Deshalb gehört zu jeder Ursachenanalyse auch die Frage, welche Kennzahlen künftig dauerhaft erfasst werden.

Miniatur-Szene: Leitstand mit drei Dashboard-Bildschirmen, Alarmglocke und rotierender Radarschüssel
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Diagnose-Reihenfolge bei einem langsamen Linux-Server

  1. 01 Last einordnen: uptime, top
  2. 02 CPU: us, sy, wa, steal
  3. 03 Speicher: vmstat, OOM-Log
  4. 04 I/O: iostat, iotop
  5. 05 Netzwerk: ss, ip -s link
  6. 06 Befund ins Monitoring
Was du mitnimmst

Die Diagnose-Reihenfolge, die dich zur Ursache führt

Arbeite die Ebenen immer in derselben Reihenfolge ab und grenze mit jedem Schritt ein Subsystem aus. So kommst du auch unter Zeitdruck zu einer belastbaren Aussage statt zu einem Neustart auf Verdacht.

Last einordnen statt bewerten

Lies den Load Average im Verhältnis zur Anzahl der Kerne aus nproc und vergleiche die Werte über 1, 5 und 15 Minuten. Steigt die Kurve, kommt das Problem gerade erst an, fällt sie, hast du den Peak bereits hinter dir. In top oder htop trennst du dann sofort us, sy, wa und st voneinander.

CPU-gebunden oder wartend

Hohe Werte bei us zeigen auf Anwendungscode, hohe sy-Werte auf Syscalls und Kernel-Arbeit, steal time auf einen überbuchten Hypervisor. Mit ps -eo state,pid,comm filterst du Prozesse im Status D heraus, und pidstat sowie perf top helfen dir, die verursachende Codestelle einzugrenzen.

Speicher und Swap richtig lesen

vmstat 1 liefert dir mit si und so die tatsächliche Swap-Aktivität, free -h trennt Cache vom belegten Speicher. Prüfe mit dmesg oder journalctl -k, ob der OOM-Killer bereits zugeschlagen hat, und wirf einen Blick auf memory.max und memory.pressure der betroffenen cgroups.

I/O bis zum Datenträger verfolgen

Mit iostat -xz 1 bewertest du await, aqu-sz und den Durchsatz pro Device, mit iotop oder pidstat -d findest du den schreibenden Prozess. Danach klärst du, ob Dateisystem, LVM-Layout, ein degradiertes RAID oder ein volles Filesystem mit knappen Inodes die Bremse ist.

Netzwerk und Dienste prüfen

ss -tan zeigt dir gefüllte Recv-Q und Send-Q sowie Verbindungen im Zustand TIME_WAIT, ip -s link deckt Fehler und Drops auf der Schnittstelle auf. Ergänzend gehören DNS-Auflösung, MTU und Latenz zum Backend-System in die Prüfung, bevor du die Anwendung selbst verdächtigst.

Befund sichern und dauerhaft messen

Halte Messwerte, Zeitpunkt und Änderungen aus dem Change-Log schriftlich fest, damit die Ursache nachvollziehbar bleibt. Anschließend übernimmst du die entscheidenden Kennzahlen in dein Monitoring, damit der nächste Vorfall bereits eine Zeitreihe zum Vergleich hat.

Tutorial

Systematisch messen statt raten

Bei Leistungsproblemen ist die Versuchung groß, an bekannten Stellschrauben zu drehen. Das kostet Zeit und verdeckt die Ursache. Dieser Teil geht in einer festen Reihenfolge vor: erst der Überblick, dann die vier Ressourcen einzeln, zuletzt die Anwendung selbst. In den meisten Fällen bist du nach dem zweiten Kapitel fertig.

01

Sechzig Sekunden Überblick

Bevor du in die Tiefe gehst, verschaffst du dir ein Bild. Diese Befehle beantworten die Frage, in welche Richtung du überhaupt suchen musst.

Der Standardeinstieg
uptime                    # Lastdurchschnitt 1, 5, 15 Minuten
dmesg -T | tail -20       # Kernel-Meldungen, OOM-Kills, I/O-Fehler
vmstat 1 5                # CPU, Speicher, Swap, I/O im Verlauf
mpstat -P ALL 1 3         # Last je Kern, erkennt Ungleichverteilung
pidstat 1 3               # Verbrauch je Prozess
iostat -xz 1 3            # Auslastung je Datenträger
free -h                   # Speicher, Spalte 'available' zählt
ss -s                     # Socket-Übersicht

Aus dem Paket sysstat. Die Reihenfolge stammt von Brendan Gregg und ist bewusst so gewählt: Sie grenzt in einer Minute ein, ob CPU, Speicher, Datenträger oder Netz das Problem ist.

02

CPU

Echte CPU-Sättigung ist seltener als vermutet. Häufiger sind einzelne Prozesse, die einen Kern belegen, oder Wartezeiten, die als Last erscheinen.

Eingrenzen
# Wer verbraucht?
top -o %CPU
pidstat -u 1 5

# Ein einzelner Kern am Anschlag, der Rest langweilt?
mpstat -P ALL 1 3

# Steckt der Prozess in Systemaufrufen fest?
sudo strace -c -p <PID> -f

# Wo genau verbringt er die Zeit?
sudo perf top -p <PID>

Ein einzelner ausgelasteter Kern bei ansonsten ruhigem System deutet auf einen Prozess ohne Parallelisierung hin. Mehr Kerne helfen dort nicht, nur ein schnellerer Takt oder eine andere Implementierung.

Ein häufig übersehener Punkt sind Frequenzeinstellungen. Server im Energiesparmodus takten unter wechselnder Last träge hoch, was sich als unerklärliche Latenz zeigt. cpupower frequency-info verrät den aktiven Governor, performance statt powersave ist auf Datenbankservern oft die einfachste Verbesserung überhaupt.

03

Speicher

Der Klassiker: 'Der Server hat nur noch 200 MB frei.' Das ist meistens kein Problem, sondern gewollt. Kritisch wird es erst, wenn Swapping einsetzt oder der OOM-Killer zuschlägt.

Richtig hinsehen
free -h
# Es zählt 'available', nicht 'free'. Cache wird bei Bedarf freigegeben.

# Läuft Swapping? si/so müssen dauerhaft nahe 0 sein
vmstat 1 10

# Wer belegt am meisten?
ps aux --sort=-%mem | head

# Hat der OOM-Killer zugeschlagen?
sudo dmesg -T | grep -i -E 'out of memory|killed process'
sudo journalctl -k | grep -i oom

# Wer swappt konkret?
for p in /proc/*/status; do awk '/^Name|^VmSwap/{printf "%s ", $2}END{print ""}' $p; done | sort -k2 -h -r | head

Ein Wert bei si und so von dauerhaft über null bedeutet, dass das System aktiv auslagert. Das ist der Punkt, an dem alles zäh wird, unabhängig von der CPU-Last.

04

Datenträger und I/O

In der Praxis ist das die häufigste Ursache. Ein hoher %iowait bedeutet, dass die CPU wartet, während die Platte nicht hinterherkommt.

Messen
# %util nahe 100 und hohe await-Werte sind das Signal
iostat -xz 1 5

# Welcher Prozess erzeugt die Last?
sudo iotop -oPa

# Latenz je Anfrage im Detail
sudo biolatency 2>/dev/null || sudo bpftrace -e 'tracepoint:block:block_rq_complete { @ = hist(args->nr_sector); }'

# Ist die Platte gesund?
sudo smartctl -a /dev/sda | grep -E 'Reallocated|Pending|Offline_Unc|Wear'

await ist die Wartezeit je Anfrage in Millisekunden. Bei einer SSD sind Werte über 10 auffällig, bei einer rotierenden Platte über 50. Steigt aqu-sz gleichzeitig an, stauen sich die Anfragen.

Bevor du Hardware tauschst, prüfe zwei Dinge. Erstens den Scheduler: Auf NVMe-SSDs ist none richtig, auf rotierenden Platten bfq oder mq-deadline. Ein falscher Scheduler kostet spürbar Durchsatz. Zweitens die Dateisystemoptionen: noatime spart bei lesenden Lasten eine erstaunliche Menge Schreibzugriffe, weil sonst jeder Lesevorgang den Zugriffszeitstempel aktualisiert.

Beides prüfen
cat /sys/block/nvme0n1/queue/scheduler
echo none | sudo tee /sys/block/nvme0n1/queue/scheduler   # dauerhaft über udev-Regel

findmnt -no TARGET,OPTIONS /var/lib/mysql
# relatime ist der Standard und meist ausreichend, noatime spart mehr

Auf Dateisystemen mit vielen kleinen Lesezugriffen, etwa Mailspeichern oder Webverzeichnissen, ist noatime eine der wirksamsten Einzelmaßnahmen.

05

Netzwerk

Wenn CPU, Speicher und Platte unauffällig sind, die Anwendung aber trotzdem hängt, lohnt der Blick auf Verbindungen und Fehlerzähler.

Prüfen
# Fehler und verworfene Pakete
ip -s link show
netstat -s | grep -iE 'retrans|drop|overflow|listen'

# Überläuft die Accept-Queue? Bei lauschenden Sockets ist Send-Q das
# konfigurierte Limit und Recv-Q der aktuelle Fuellstand.
ss -ltn
# Zaehler der tatsaechlichen Ueberlaeufe:
nstat -az TcpExtListenOverflows TcpExtListenDrops

# Wie viele Verbindungen wohin?
ss -tan state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

# Latenz und Paketverlust auf dem Weg
mtr -rw ziel.example.com

Ein wachsender Wert bei listen queue overflows bedeutet, dass die Anwendung Verbindungen nicht schnell genug annimmt. Dann hilft nicht mehr Bandbreite, sondern ein größeres net.core.somaxconn und mehr Worker in der Anwendung.

06

Was in der Praxis dahintersteckt

Nach vielen solchen Analysen wiederholen sich die Ursachen.

Häufige Befunde

SymptomHäufigste UrsacheNächster Schritt
Hohe Last, niedrige CPU-NutzungWarten auf I/Oiostat -xz, dann Datenbank oder Backup als Verursacher suchen
Alles zäh, Load moderatSwappingvmstat prüfen, Speicherfresser finden, swappiness senken
Ein Kern voll, Rest leerAnwendung ohne ParallelisierungTakt statt Kerne, oder Architektur der Anwendung ansehen
Nachts regelmäßig langsamBackup, Scrub oder Cronjobsystemd-analyze, Timer und Cron prüfen, Fenster entzerren
Sporadische AussetzerNetzwerk oder defekte Platteip -s link und smartctl
Gut zu wissen

Häufige Fragen zu Performance-Analyse unter Linux

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Warum ist die Load hoch, obwohl die CPU fast idle ist?
Der Load Average unter Linux berücksichtigt neben laufenden Prozessen auch solche im unterbrechungsfreien Schlaf im Status D. Warten viele Prozesse auf Block-I/O oder auf ein nicht erreichbares Netzlaufwerk, steigt die Load, ohne dass Rechenzeit verbraucht wird. Prüfe in diesem Fall zuerst iowait in top sowie await pro Device in iostat -xz 1.
Ab welchem Wert ist iowait wirklich kritisch?
Einen festen Grenzwert gibt es nicht, weil iowait immer im Verhältnis zur Anzahl der Kerne und zum Aufgabenprofil des Systems steht. Auf einem Datenbank-Host sind kurzzeitige Spitzen normal, dauerhaft zweistellige Werte in Kombination mit steigenden await-Zeiten und wachsender Queue-Länge sind dagegen ein klarer Hinweis auf ein überlastetes Storage-Backend.
Sollte ich Swap abschalten, wenn der Server langsam ist?
Nein, das Abschalten behebt keine Ursache und erhöht nur das Risiko, dass der OOM-Killer Prozesse beendet. Entscheidend ist nicht der belegte Swap, sondern die Ein- und Auslagerungsrate si und so in vmstat. Bleibt sie nahe null, ist der belegte Swap unkritisch und du suchst die Ursache in einem anderen Subsystem.
Welche Werkzeuge brauche ich mindestens für eine saubere Analyse?
Für die meisten Störungen reichen die Standardwerkzeuge aus, konkret top oder htop, vmstat, iostat und pidstat aus dem Paket sysstat, iotop, ss aus iproute2 sowie journalctl. Ergänzend lohnt es sich, sysstat mit sar dauerhaft aktiv zu haben, weil du damit auch rückwirkend in Zeitreihen schauen kannst.
Wie verhindere ich, dass sich der Vorfall wiederholt?
Übernimm die Kennzahlen, die den Vorfall sichtbar gemacht haben, in ein dauerhaftes Monitoring mit Schwellwerten und Historie. Prometheus mit Node Exporter und Grafana ist dafür ein verbreiteter Weg, Zabbix oder Naemon und Nagios erfüllen denselben Zweck. Wichtig ist vor allem, dass du einen Normalzustand dokumentiert hast, gegen den du im nächsten Störfall vergleichen kannst.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Performance-Analyse unter Anleitung üben

Im Linux Troubleshooting Training arbeitest du bei cmt an nachgestellten Störfällen und übst die Diagnose-Reihenfolge an echten Systemen statt an Theorie. Wenn du tiefer in Kernel-Parameter, Scheduler und Ressourcensteuerung einsteigen willst, passt der Linux Systemanpassungen Deep Dive, für Storage- und Dateisystemthemen der Kurs Linux Storage und Dateisysteme und für den Aufbau eines dauerhaften Monitorings der Grundkurs Monitoring mit Prometheus und Grafana. Alle Kurse gibt es als Präsenztermin oder Live-Online, und wenn du unsicher bist, welcher Kurs zu deiner Situation passt, sprich uns einfach an.