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.
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.
Diagnose-Reihenfolge bei einem langsamen Linux-Server
- 01 Last einordnen: uptime, top
- 02 CPU: us, sy, wa, steal
- 03 Speicher: vmstat, OOM-Log
- 04 I/O: iostat, iotop
- 05 Netzwerk: ss, ip -s link
- 06 Befund ins Monitoring
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.
Kurse zu Performance-Analyse unter Linux bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu Performance-Analyse unter Linux
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktWarum ist die Load hoch, obwohl die CPU fast idle ist?
Ab welchem Wert ist iowait wirklich kritisch?
Sollte ich Swap abschalten, wenn der Server langsam ist?
Welche Werkzeuge brauche ich mindestens für eine saubere Analyse?
Wie verhindere ich, dass sich der Vorfall wiederholt?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Der Kursinhalt entsprach voll meinen Erwartungen, die richtige Mischung aus Theorie und Praxis.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
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.