Serverlast im Terminal: top, htop und Co.

Die Seite ist langsam, aber warum? Mit einer Handvoll Standard-Befehlen siehst du per SSH live, wer gerade CPU, Arbeitsspeicher oder Festplatte beansprucht — top, htop, free, df und ps sind auf jedem Linux-Server vorhanden. Dieser Artikel erklärt, wie du die Ausgaben liest, statt nur auf bunte Zahlen zu starren. Er ist Teil unserer Performance-Analyse-Serie: GoAccess beantwortet das Wer greift zu, die Werkzeuge hier das Was lastet den Server aus.

Voraussetzungen

• SSH-Zugang — siehe SSH-Zugang einrichten.
• Auf Shared Hosting siehst du nur deine eigenen Prozesse (CloudLinux isoliert die Kunden voneinander) — für deine Limits ist dort die Ressourcennutzung im Panel die bessere Anlaufstelle. Auf Managed Servern siehst du das komplette System.

Der Schnellcheck in 60 Sekunden

1. Verschaff dir den Überblick: uptime — die drei Zahlen am Ende sind der Load Average (Details unten).
2. Finde den Verursacher: top — die Prozessliste ist nach CPU-Verbrauch sortiert, oben steht der Kandidat. Beenden mit q.
3. Prüf den Arbeitsspeicher: free -h — entscheidend ist die Spalte available.
4. Prüf den Speicherplatz: df -h — eine Partition bei 100 % erklärt viele „unerklärliche” Fehler.

Zeigt keiner der vier Blicke etwas Auffälliges, ist die Ursache oft gar nicht die Maschine, sondern der Traffic — dann lohnt der Blick in die Access-Logs.

Load Average verstehen

uptime (und die erste Zeile von top) zeigt drei Zahlen: die durchschnittliche Systemlast Anzahl der Prozesse, die gerade rechnen oder auf CPU bzw. Festplatte warten — gemittelt über 1, 5 und 15 Minuten. der letzten 1, 5 und 15 Minuten:

15:42:01 up 84 days,  3:12,  1 user,  load average: 2.31, 1.87, 0.92

Die Faustregel: Load ≤ Anzahl der CPU-Kerne = entspannt. Wie viele Kerne dein Server hat, verrät nproc. Ein Load von 2,3 ist auf 8 Kernen Grundrauschen, auf 2 Kernen ein Warnsignal. Und die drei Zahlen im Vergleich erzählen die Richtung: 1-Minuten-Wert deutlich über dem 15-Minuten-Wert heißt, die Last baut sich gerade auf — umgekehrt läuft die Spitze bereits ab.

top lesen

top ist das Live-Dashboard des Servers und läuft überall ohne Installation. Die Kopfzeilen zuerst:

top - 15:42:01 up 84 days,  load average: 2.31, 1.87, 0.92
Tasks: 213 total,   2 running, 211 sleeping
%Cpu(s): 62.1 us,  8.4 sy,  0.0 ni, 27.3 id,  1.9 wa
MiB Mem :  15895.4 total,   1204.1 free,   9871.2 used,   4820.1 buff/cache

• us (user) — Rechenzeit deiner Anwendungen: PHP, MySQL, Node. Hoch bei echter Arbeit.
• sy (system) — Kernel-Anteil. Dauerhaft hohe Werte sind ungewöhnlich.
• id (idle) — Reserve. Solange hier etwas übrig ist, verhungert niemand.
• wa ( I/O-Wait I/O-Wait: Anteil der Zeit, in der die CPU nichts tut, weil sie auf Festplatte oder Netzwerk-Storage wartet. ) — der unterschätzte Wert: Die CPU wartet auf den Datenträger. Dauerhaft über ~10 % heißt, der Engpass ist nicht die CPU, sondern das Storage — typisch bei Backup-Läufen oder wild schreibenden Prozessen.

In der Prozessliste darunter zählen vor allem %CPU, %MEM, RES (tatsächlich belegter Arbeitsspeicher) und COMMAND. Die nützlichsten Tasten:

Taste	Wirkung
P	nach CPU sortieren (Standard)
M	nach Arbeitsspeicher sortieren
1	Auslastung pro CPU-Kern einzeln anzeigen
c	vollständige Befehlszeile statt nur Prozessname
q	beenden

htop: dasselbe, nur angenehmer

htop zeigt dieselben Daten mit Farben, Balken pro Kern und scrollbarer Prozessliste — sortieren per Mausklick auf die Spaltenüberschrift, Baumansicht mit F5 (zeigt, welcher Prozess welche Kinder gestartet hat, etwa PHP-Worker unter ihrem Pool). Für die Analyse kannst du beide austauschbar verwenden; alles aus dem top-Abschnitt gilt genauso. Fehlt htop auf deinem Server, tut es top — oder du fragst per Ticket nach der Installation.

free -h: Arbeitsspeicher richtig deuten

               total        used        free      shared  buff/cache   available
Mem:            15Gi       9,6Gi       1,2Gi       412Mi       4,7Gi       5,4Gi
Swap:             0B          0B          0B

Der häufigste Fehlschluss: „free ist fast leer, der Server ist voll!” — ist er nicht. Linux nutzt ungenutzten RAM als Datei-Cache (buff/cache) und gibt ihn sofort frei, wenn ihn ein Prozess braucht. Die einzige Zahl, die zählt, ist available. Erst wenn die gegen null läuft, wird es eng. Und die Swap-Zeile zeigt bei uns immer 0B — das ist Absicht, keine Fehlkonfiguration: Warum unsere Server ohne Swap laufen.

df -h und du: wenn der Platz ausgeht

Eine volle Partition produziert die kreativsten Fehlermeldungen — Datenbank nimmt keine Schreibzugriffe an, Sessions brechen ab, Mails bleiben liegen. Deshalb gehört df -h in jeden Schnellcheck:

df -h                     # alle Partitionen mit Füllstand
du -sh ~/* | sort -rh | head   # die größten Verzeichnisse in deinem Home, absteigend

Mit du hangelst du dich dann ins verdächtige Verzeichnis vor (du -sh ~/httpdocs/* | sort -rh | head) — klassische Platzfresser sind Log-Dateien, alte Backups und Cache-Verzeichnisse.

ps: gezielt nach Prozessen suchen

Wenn du nicht zusehen, sondern eine konkrete Frage beantworten willst:

ps aux --sort=-%cpu | head    # Top-CPU-Verbraucher als Momentaufnahme
ps aux --sort=-%mem | head    # Top-Speicher-Verbraucher
ps aux | grep php             # läuft ein bestimmter Prozess überhaupt?

Die Momentaufnahme eignet sich auch für Tickets: Die Ausgabe lässt sich kopieren, ein top-Bildschirm nicht.

Wenn etwas schiefläuft

Load ist hoch, aber kein Prozess zeigt nennenswerte CPU

Die Klassiker-Falle: Load zählt auch Prozesse, die auf den Datenträger warten. Der Engpass ist dann I/O, nicht Rechenleistung.

Lösung: In top auf den wa-Wert schauen. Ist er dauerhaft zweistellig, den Schreib-Verursacher suchen (laufendes Backup? Log-Flut? Import-Job?) — und wenn nichts Eigenes zu finden ist, Ticket mit Zeitpunkt und top-Ausgabe.

top zeigt fast keine Prozesse

Auf Shared Hosting ist das normal: CloudLinux isoliert die Kunden, du siehst nur deine eigenen Prozesse — und die Load-Anzeige gehört zum ganzen Server, nicht zu deinem Anteil.

Lösung: Für deine tatsächlichen Limits und deren Auslastung die Ressourcennutzung im Panel verwenden — sie zeigt genau die Werte, nach denen dein Account gedrosselt würde.

Die Lastspitze ist vorbei, bevor du hinschauen kannst

top zeigt nur das Jetzt — nächtliche oder kurze Spitzen erwischst du damit nicht.

Lösung: Rückwirkend helfen die Verlaufs-Graphen der Ressourcennutzung und die Access-Log-Analyse mit GoAccess — Traffic-Wellen und Lastspitzen decken sich erstaunlich oft. Wiederkehrende Zeitpunkte deuten auf Cronjobs.

Ein Prozess belegt immer mehr Speicher, bis er beendet wird

Wächst RES eines Prozesses stetig, bis er verschwindet, hat vermutlich der OOM-Killer eingegriffen (bei Containern: Exit-Code 137).

Lösung: Speicherbedarf des Dienstes begrenzen (Heap-Limits, Worker-Anzahl, Cache-Deckel). Hintergrund und Einordnung: Warum unsere Server ohne Swap laufen.

Verwandte Artikel

• Ressourcennutzung im Panel prüfen — dieselben Fragen ohne Terminal, mit Verlauf.
• GoAccess: Zugriffe selbst analysieren — wenn die Last von außen kommt.
• Warum unsere Server ohne Swap laufen — die Speicher-Seite im Detail.
• Cronjob einrichten — häufige Quelle wiederkehrender Lastspitzen.

Du kommst nicht weiter?

Load hoch und kein Verursacher in Sicht, oder die Werte ergeben kein Bild? Ticket im Kundencenter öffnen — häng die Ausgaben von uptime, free -h und ps aux --sort=-%cpu | head an, dann schauen wir gemeinsam drauf.