Linux-Server langsam: CPU, RAM, I/O oder Netzwerk? Den Engpass in sieben Schritten finden

Wenn ein Linux-Server langsam ist, steckt fast immer eine von vier Ressourcen dahinter: CPU, Arbeitsspeicher, Festplatten-I/O oder Netzwerk. Mit den Bordmitteln uptime, vmstat, iostat und top finden Sie in wenigen Minuten heraus, welche davon der Engpass ist und welcher Prozess ihn verursacht. Erst danach entscheiden Sie, ob Sie optimieren, aufräumen oder mehr Ressourcen einplanen.

Der häufigste Fehler in dieser Situation ist nicht fehlendes Wissen, sondern die falsche Reihenfolge: Es wird neu gestartet, ein Dienst hochskaliert oder die Konfiguration geändert, bevor klar ist, wo es überhaupt hakt. Dieser Beitrag zeigt eine Diagnose, die vom Groben ins Feine geht und bei der jeder Schritt den nächsten begründet.

Linux-Server langsam: Woran erkennen Sie, welche Ressource bremst?

Der erste Blick gilt dem Load Average. Viele lesen ihn als CPU-Auslastung, das ist er unter Linux aber nicht. Er zählt Prozesse, die rechnen wollen, und zusätzlich Prozesse, die im Zustand D auf Ein- und Ausgabe warten. Ein hoher Load kann also auch bedeuten, dass die CPU fast nichts tut und alle auf die Festplatte warten.

Deshalb ist der Load nur ein Symptom, keine Diagnose. Er sagt Ihnen, dass etwas staut. Wo es staut, zeigen erst die Detailwerte von CPU, Speicher und Datenträgern.

Als grobe Orientierung gilt: Liegt der Load dauerhaft über der Anzahl der CPU-Kerne, warten Prozesse. Kurze Spitzen sind normal, etwa während eines Backups oder Cronjobs. Entscheidend ist, ob der Wert über 15 Minuten erhöht bleibt.

Die Diagnose in der richtigen Reihenfolge

Die folgenden sieben Schritte funktionieren auf praktisch jeder Distribution. Für iostat und sar benötigen Sie das Paket sysstat, für iotop das gleichnamige Paket.

1. Last einordnen: uptime und nproc zeigen den Load der letzten 1, 5 und 15 Minuten und die Zahl der Kerne. Steigt der 1-Minuten-Wert gerade erst, ist das Problem frisch. Ist der 15-Minuten-Wert am höchsten, klingt es bereits ab.
2. Gesamtbild mit vmstat: vmstat 1 10 liefert zehn Messungen im Sekundentakt. Hier sehen Sie auf einen Blick, ob CPU, Swap oder I/O auffällig sind.
3. Verursacher finden: top oder htop, sortiert nach CPU (Taste P) oder Speicher (Taste M), zeigt die Prozesse hinter der Last.
4. Datenträger prüfen: iostat -xz 1 zeigt Auslastung und Wartezeiten pro Gerät, iotop -o die Prozesse, die gerade schreiben oder lesen.
5. Speicher prüfen: free -h und ein Blick ins Kernel-Log auf Einträge des OOM-Killers.
6. Netzwerk und Verbindungen: ss -s und die Antwortzeiten externer Abhängigkeiten wie Datenbank, DNS oder APIs.
7. Logs zum Zeitpunkt: journalctl --since "30 min ago" -p warning zeigt Warnungen und Fehler aus dem Zeitraum, in dem die Verlangsamung begann.

Die Ausgabe von vmstat ist der wichtigste Wegweiser. So lesen Sie die relevanten Spalten:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 412308  98112 2210440    0    0     4    38  910 1650 88 10  2  0  0
 1  7 524288  60120  10220  180344  812  950  4100  2900 1200 2100  5  4 21 70  0

• r deutlich über der Kernzahl und us hoch: Die CPU ist der Engpass (erste Zeile).
• b erhöht und wa hoch: Prozesse warten auf I/O (zweite Zeile).
• si und so dauerhaft über null: Der Server lagert Speicher aus und wird dadurch zäh.
• st dauerhaft erhöht: Auf einer virtuellen Maschine bekommt Ihr System weniger CPU-Zeit, als es anfordert.

CPU-Engpass: Wenn tatsächlich gerechnet wird

Ist us (Anwendungen) oder sy (Kernel) hoch und id nahe null, arbeitet die CPU am Limit. Den Verursacher finden Sie schnell:

ps -eo pid,user,comm,%cpu,%mem --sort=-%cpu | head -n 10

Typische Ursachen in KMU-Umgebungen sind PHP- oder Java-Prozesse unter Last, Bots und Crawler, die eine Website abgrasen, festhängende Cronjobs, die sich überlappen, und Kompressionsjobs von Backups zur Geschäftszeit. Ein unerwarteter Prozess mit hoher CPU-Last, etwa mit zufälligem Namen oder unter einem Webserver-Benutzer, kann auch auf einen Kryptominer nach einer Kompromittierung hinweisen. Das sollten Sie nicht ignorieren.

Ein hoher sy-Anteil deutet eher auf viele Systemaufrufe hin, zum Beispiel durch sehr viele kleine Netzwerkverbindungen oder Dateioperationen. Hier lohnt der Blick in die Spalte cs (Kontextwechsel).

Auf Cloud-Servern gibt es eine Sonderform: Steal Time. Ist st über längere Zeit merklich erhöht, wartet Ihre VM auf den physischen Host. Das können Sie innerhalb des Systems nicht beheben, sondern nur mit dem Anbieter klären oder durch einen Wechsel der Instanz.

Arbeitsspeicher: Wenn Swap den Server ausbremst

Bei free -h ist die Spalte available entscheidend, nicht free. Linux nutzt freien Speicher als Dateicache (buff/cache) und gibt ihn bei Bedarf sofort zurück. Ein Server mit wenig "free" und viel "available" ist gesund.

Kritisch wird es, wenn available knapp ist und vmstat gleichzeitig dauerhafte Werte in si und so zeigt. Dann schiebt der Kernel ständig Speicherseiten zwischen RAM und Swap hin und her. Das fühlt sich an wie ein I/O-Problem, ist aber ein Speicherproblem.

Ob der Kernel bereits Prozesse beenden musste, zeigt das Kernel-Log:

dmesg -T | grep -iE "out of memory|killed process"
journalctl -k --since today | grep -i oom

Häufige Ursachen sind zu großzügig konfigurierte Worker-Pools, etwa pm.max_children bei PHP-FPM oder zu viele Datenbankverbindungen, Speicherlecks in Anwendungen, die erst nach Tagen sichtbar werden, und Datenbank-Puffer, die größer eingestellt sind, als der Server neben den anderen Diensten verkraftet.

Festplatten-I/O: Der am häufigsten unterschätzte Grund

Hoher Load bei niedriger CPU-Auslastung und hohem wa ist das klassische Bild eines I/O-Engpasses. iostat zeigt, welches Gerät betroffen ist:

iostat -xz 1 5

Achten Sie auf drei Spalten: %util zeigt, wie viel Zeit das Gerät beschäftigt war, r_await und w_await die durchschnittliche Wartezeit pro Lese- und Schreibzugriff in Millisekunden. Bei Netzwerk- oder Software-definiertem Speicher ist %util nur eingeschränkt aussagekräftig, weil viele Zugriffe parallel laufen. Steigende Wartezeiten sind dort der verlässlichere Hinweis.

Mit iotop -o sehen Sie dann, welcher Prozess die Zugriffe erzeugt. Typische Kandidaten sind Backup-Läufe, Logrotation mit Kompression, Datenbank-Dumps, Virenscanner und Indexierungsdienste.

Ein Sonderfall: Ein Dateisystem, das fast voll ist, wird spürbar langsamer, und bei vollständig belegter Platte schlagen Schreibvorgänge fehl. Prüfen Sie mit df -h und df -i Platz und Inodes. Wie Sie dabei sicher vorgehen, beschreibt unser Beitrag zum Thema volle Festplatte auf dem Linux-Server.

Netzwerk und externe Abhängigkeiten

Nicht jede Langsamkeit entsteht auf dem Server selbst. Wenn alle lokalen Werte unauffällig sind, die Anwendung aber träge antwortet, wartet sie oft auf etwas anderes.

ss -s
ss -tan state established | wc -l
ss -tan state time-wait | wc -l
time getent hosts example.org

Viele Verbindungen im Zustand TIME-WAIT deuten auf Anwendungen hin, die für jede Anfrage eine neue Verbindung aufbauen. Ein langsamer DNS-Resolver verzögert jede ausgehende Verbindung, das zeigt der time-Aufruf. Hängt die Anwendung an einer Datenbank auf einem anderen Host, an einem SMTP-Relay oder einer externen API, prüfen Sie deren Antwortzeiten direkt, etwa mit curl -w "%{time_total}\n" -o /dev/null -s URL.

Auch ip -s link lohnt einen Blick: Steigende Zähler bei errors oder dropped weisen auf Probleme in der Netzwerkschicht hin.

Wenn alle Systemwerte normal aussehen

Sind CPU, Speicher, I/O und Netzwerk unauffällig, liegt das Problem fast immer in der Anwendung. Typisch sind langsame Datenbankabfragen ohne passenden Index, Sperren in der Datenbank, ausgeschöpfte Worker-Pools, bei denen Anfragen in einer Warteschlange stehen, obwohl der Server Kapazität hätte, oder abgelaufene Caches.

Hier helfen das Slow-Query-Log der Datenbank, der Status-Endpunkt von PHP-FPM und die Fehlerlogs des Webservers. Für WordPress-Installationen haben wir das Vorgehen ausführlich beschrieben: WordPress langsam und die Frage, ob Server, Plugins oder Datenbank bremsen.

Optimieren oder aufrüsten? Eine Entscheidungshilfe

Mehr Ressourcen lösen ein Problem nur, wenn tatsächlich eine Ressource knapp ist und die Last legitim ist. Wer aufrüstet, bevor der Engpass identifiziert ist, verschiebt das Problem meist nur, statt es zu lösen.

Diese Fragen helfen bei der Entscheidung:

• Ist die Last durch echte Nutzung gewachsen, oder erzeugt ein einzelner Prozess, Bot oder Job sie unnötig?
• Tritt der Engpass nur zu bestimmten Zeiten auf? Dann reicht oft das Verlegen von Backups und Cronjobs in ruhige Zeiten.
• Lässt sich die Anwendung mit vertretbarem Aufwand optimieren, etwa durch einen Index, einen Cache oder kleinere Worker-Pools?
• Ist der Engpass über Wochen gleichmäßig gewachsen? Dann ist mehr Kapazität die richtige Antwort.
• Liegt die Ursache außerhalb Ihres Systems, etwa bei Steal Time oder einem externen Dienst? Dann hilft kein Tuning, sondern nur ein Gespräch mit dem Anbieter.

Wenn Sie aufrüsten, dann gezielt: Mehr CPU hilft nicht bei einem I/O-Engpass, mehr RAM nicht bei einer langsamen externen API. Wie Sie den Bedarf aus Messwerten ableiten, zeigt der Beitrag Server richtig dimensionieren mit Kapazitätsplanung statt Bauchgefühl.

Damit der nächste Engpass früher auffällt

Die Diagnose ist deutlich einfacher, wenn Sie wissen, wie der Server im Normalzustand aussieht. Ohne diese Baseline lässt sich kaum beurteilen, ob ein Load von 3 oder eine Wartezeit von 10 Millisekunden ungewöhnlich ist.

Ein einfacher Einstieg ist sysstat mit aktivierter Datensammlung. Damit können Sie auch nachträglich auf die Werte von gestern oder letzter Woche zurückblicken:

systemctl enable --now sysstat
sar -u -f /var/log/sysstat/sa$(date +%d -d yesterday)
sar -r
sar -d

Der Pfad zu den Dateien unterscheidet sich je nach Distribution, auf RHEL-basierten Systemen liegt er unter /var/log/sa/. Langfristig ersetzt das kein Monitoring mit Alarmierung, aber es beantwortet die wichtigste Frage nach einem Vorfall: Seit wann war es so, und was hat sich geändert?

Halten Sie außerdem fest, welche Jobs wann laufen. Viele Verlangsamungen, die als rätselhaft gelten, fallen exakt auf den Start eines Backups, einer Logrotation oder eines Reports.

Diagnose und Betrieb abgeben

Nicht jedes Unternehmen hat die Zeit, Performanceprobleme selbst zu analysieren. Eine Möglichkeit ist, den Serverbetrieb an einen Dienstleister zu übergeben. Bei NETARO sind etwa die Cloud Server in Frankfurt als Managed-Variante buchbar, bei der Härtung, Updates, Backups und 24/7-Monitoring übernommen werden. Welche Aufgaben im Managed Hosting enthalten sind, ist dort beschrieben. Unabhängig davon bleibt die Diagnosereihenfolge aus diesem Beitrag dieselbe, ob Sie sie selbst anwenden oder von einem Dienstleister einfordern.

FAQ

Welcher Load Average ist bei einem Linux-Server normal?

Das hängt von der Zahl der CPU-Kerne ab. Als Faustregel gilt ein Load, der dauerhaft unter der Kernzahl liegt, als unkritisch. Kurze Spitzen darüber sind normal. Da der Load unter Linux auch auf I/O wartende Prozesse zählt, sollten Sie ihn immer zusammen mit vmstat betrachten.

Warum ist mein Server langsam, obwohl die CPU kaum ausgelastet ist?

Meist warten Prozesse auf die Festplatte, auf ausgelagerten Speicher oder auf externe Dienste wie eine Datenbank oder einen DNS-Resolver. Hohe Werte in den vmstat-Spalten wa, b, si oder so zeigen, in welche Richtung Sie weitersuchen sollten.

Hilft ein Neustart, wenn der Linux-Server langsam ist?

Ein Neustart beseitigt oft das Symptom, etwa ein Speicherleck oder festhängende Prozesse, aber nicht die Ursache. Außerdem gehen dabei die Hinweise verloren, die Sie zur Diagnose brauchen. Sichern Sie vorher zumindest die Ausgaben von top, vmstat, free -h und die relevanten Logs.

Was bedeutet Steal Time auf einem virtuellen Server?

Steal Time ist die Zeit, in der Ihre VM CPU-Leistung anfordert, der physische Host sie aber anderen Aufgaben zuteilt. Ist der Wert st dauerhaft erhöht, können Sie das innerhalb des Systems nicht beheben. Klären Sie es mit dem Anbieter oder wechseln Sie auf eine andere Instanz.