Load Average unter Linux: Was bedeutet die Serverlast?

Was ist die Load Average und was sagt sie über Ihren Server aus?

Die Load Average ist unter Linux die durchschnittliche Zahl der Prozesse, die auf einer CPU laufen, auf eine CPU warten oder im nicht unterbrechbaren Schlaf auf Festplatten I/O warten, gemittelt über 1, 5 und 15 Minuten. Linux rechnet sie nicht auf die Kernanzahl um; deshalb lesen Sie den Wert immer zusammen mit der Zahl Ihrer CPUs.

Im Alltag sprechen viele von "Serverlast" oder "Systemlast". Allerdings klingt das nach einem Prozentwert, und die Load Average ist gerade kein Prozentwert. Konkret misst sie eine Warteschlange. Sie beantwortet also nicht die Frage "wie voll ist die CPU?", sondern "wie viele Aufgaben wollen gerade Ressourcen?".

Die Manpage zu uptime formuliert es klar: Die Load Average ist die durchschnittliche Zahl der Prozesse in einem lauffähigen oder nicht unterbrechbaren Zustand. Ein lauffähiger Prozess nutzt die CPU oder wartet auf sie. Ein nicht unterbrechbarer Prozess wartet dagegen auf I/O, zum Beispiel auf einen Lesevorgang der Festplatte.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Daher stützt sich dieser Leitfaden auf Linux Manpages, die Kerneldokumentation und die Dokumentation von cPanel. Sie erfahren, wie Sie die drei Werte lesen, wie Sie CPU, Festplatte und Arbeitsspeicher als Ursache trennen und wann Sie das Problem besser Ihrem Hoster überlassen.

Ist die Load Average dasselbe wie die CPU Auslastung?

Nein, beide Werte messen Unterschiedliches. Die CPU Auslastung zeigt, wie viel Zeit der Prozessor in einem Zeitfenster beschäftigt war. Die Load Average zeigt dagegen, wie viele Aufgaben den Prozessor nutzen oder in der Schlange auf ihn warten. Eine CPU kann also bei 100 Prozent stehen, während erst die Load Average zeigt, wie lang die Schlange dahinter ist.

Ein einfaches Beispiel: Ein Server mit einem Kern läuft bei 100 Prozent, und in der Schlange steht genau eine Aufgabe. Die Load Average liegt dann bei etwa 1. Kommen vier weitere Aufgaben hinzu, zeigt die CPU weiterhin 100 Prozent. Die Load Average steigt jedoch Richtung 5. Im zweiten Fall wartet jede Anfrage länger.

Unter Linux kommt noch etwas hinzu. Die Load Average zählt auch Prozesse, die auf die Festplatte warten. Deshalb kann sie hoch sein, obwohl die CPU kaum ausgelastet ist. In diesem Fall liegt der Engpass meist im Speichersystem, nicht im Prozessor.

• CPU Auslastung: Wie beschäftigt der Prozessor ist.
• Load Average: Wie lang die Schlange der wartenden Aufgaben im Mittel ist.
• %wa (iowait): Anteil der Zeit, in der die CPU untätig war, während noch eine Festplattenanfrage offen war.

Kurz gesagt brauchen Sie alle drei Werte zusammen. Keiner davon liefert allein das ganze Bild.

Mit welchen Befehlen sehen Sie die Load Average?

Für diese Werte brauchen Sie keine zusätzlichen Pakete. Die Standardwerkzeuge der meisten Linux Distributionen zeigen sie direkt an. Am schnellsten geht es mit uptime.

uptimewcat /proc/loadavgtop

Eine Beispielausgabe mit fiktiven Werten sieht so aus: 10:15:02 up 12 days, 3:04, 2 users, load average: 0.52, 0.61, 0.70. Die letzten drei Zahlen stehen für die vergangenen 1, 5 und 15 Minuten. Zudem zeigt w dieselbe Zeile zusammen mit den angemeldeten Benutzern. Auch top zeigt die drei Werte in der ersten Zeile und aktualisiert sie laufend.

Die Manpage zu /proc/loadavg beschreibt das Dateiformat. Die ersten drei Felder geben die durchschnittliche Zahl der Jobs in der Run Queue (Zustand R) oder im Warten auf Festplatten I/O (Zustand D) über 1, 5 und 15 Minuten an. Das vierte Feld enthält zwei Zahlen im Format "lauffähig/gesamt". Das fünfte Feld nennt die PID des zuletzt erstellten Prozesses.

Für Skripte ist diese Datei die sauberste Quelle. Lesen Sie also direkt /proc/loadavg, statt die Ausgabe von uptime zu zerlegen, denn ihr Format ändert sich nicht mit Sprache oder Gebietsschema.

Was bedeuten die Werte für 1, 5 und 15 Minuten?

Die drei Zahlen beschreiben dieselbe Größe über verschiedene Zeitfenster. Die eigentliche Aussage steckt allerdings im Verhältnis der Werte zueinander. Es handelt sich nicht um einfache arithmetische Mittel; ältere Messungen verlieren mit der Zeit an Gewicht. Daher reagiert der Wert für 1 Minute schnell, während sich der Wert für 15 Minuten nur langsam bewegt.

• 1 Minute hoch, 15 Minuten niedrig: Die Last steigt gerade erst. Denkbar sind eine Trafficspitze, ein Cronjob oder ein Backup.
• 1 Minute niedrig, 15 Minuten hoch: Die Last sinkt. Das Problem ist vermutlich vorbei, die Ursache sollten Sie trotzdem in den Logs suchen.
• Alle drei hoch und nah beieinander: Die Last hält an. Der Server arbeitet seit einiger Zeit über seiner Kapazität.
• Alle drei niedrig: Die Schlange ist kurz. Wirkt die Website trotzdem langsam, liegt die Ursache meist in einer anderen Schicht.

Zum Beispiel sehen Sie morgens einen hohen Wert für 1 Minute und erschrecken. Sind die Werte für 5 und 15 Minuten aber ruhig, war es vermutlich nur eine kurze Spitze. Bleibt dagegen der Wert für 15 Minuten tagelang hoch, deutet das auf ein Kapazitätsproblem oder einen Softwarefehler hin.

Somit lesen Sie die drei Werte wie einen Trend: Steigt die Last, sinkt sie oder bleibt sie hoch?

Warum müssen Sie die Zahl der CPU Kerne kennen?

Linux normiert die Load Average nicht auf die Zahl der CPUs. Die Manpage zu uptime nennt dafür ein klares Beispiel. Eine Load Average von 1 bedeutet auf einem System mit einer CPU, dass es durchgehend ausgelastet war. Auf einem System mit 4 CPUs bedeutet derselbe Wert, dass es 75 Prozent der Zeit untätig war.

Dieselbe Zahl beschreibt also auf verschiedenen Servern völlig verschiedene Situationen. Zunächst ermitteln Sie deshalb, wie viele logische Prozessoren Ihr Server hat.

nproclscpu

nproc gibt die Zahl der Verarbeitungseinheiten, die dem aktuellen Prozess zur Verfügung stehen, als einzelne Zahl aus. lscpu listet Kerne, Threads und Sockel ausführlicher auf. Auf Servern mit Hyperthreading kann die Zahl der logischen Prozessoren größer sein als die der physischen Kerne.

Bei einem VPS kommt ein weiterer Punkt hinzu. Ihre virtuellen CPUs entsprechen nicht unbedingt eins zu eins physischen Kernen. Außerdem teilen sich andere Kunden auf demselben Host die Rechenzeit. Folglich kann dieselbe Load Average auf einem VPS einen anderen Druck widerspiegeln als auf einem physischen Server.

Welche Load Average ist normal, und stimmt die Regel von 1.0 pro Kern?

Die verbreitete Faustregel lautet: Nähert sich die Load Average der Kernanzahl, füllt sich die CPU Warteschlange. Etwa 1.0 pro Kern gilt als grobe Sättigungsgrenze. Allerdings ist das ein Ausgangspunkt und eine Faustregel, keine feste Grenze.

Konkret ergibt sich die Logik aus dem Beispiel der Manpage. Auf einem Server mit 4 Kernen bedeutet eine Load Average von 4, dass jeder Kern im Mittel genau eine Aufgabe hat und nichts wartet. Bei 6 warten im Mittel etwa zwei Aufgaben. Sobald der Wert die Kernanzahl übersteigt, beginnen Anfragen also zu warten.

Wenden Sie die Regel trotzdem nicht blind an, denn Linux zählt auch Prozesse, die auf die Festplatte warten. Zehn Prozesse, die an einem langsamen Speicher hängen, treiben den Wert nach oben, während die CPU fast untätig ist. Mehr Kerne lösen dann nichts.

Wir empfehlen deshalb folgendes Vorgehen:

1. Notieren Sie zunächst den normalen Bereich Ihrer Load Average an gewöhnlichen Tagen.
2. Vergleichen Sie den Wert mit der Kernanzahl, aber nutzen Sie ihn nie als einziges Signal.
3. Prüfen Sie bei einem Anstieg mit eigenen Werkzeugen, ob CPU, Festplatte oder Arbeitsspeicher dahinterstecken.
4. Entscheiden Sie dann danach, ob Nutzer die Verlangsamung tatsächlich spüren.

Zusammengefasst ist Ihr eigener Normalwert wertvoller als jede feste Grenze aus dem Netz.

Beispielrechnung: Wie lesen Sie die Load Average auf einem Server mit 4 Kernen?

Die folgende Tabelle ist eine Beispielrechnung für einen Server mit 4 logischen Prozessoren. Die Werte sind fiktiv, keine echten Messungen, und zeigen nur die Denkweise. Ihr eigener Normalbereich kann davon abweichen.

Vor allem die letzte Zeile ist wichtig. Ist die Load Average hoch, während die CPU untätig wirkt, sollten Sie zuerst das Speichersystem untersuchen, statt mehr Rechenleistung zu kaufen. Kurze Spitzen wie in der dritten Zeile gehen dagegen oft auf einen geplanten Job oder eine plötzliche Besucherwelle zurück.

Welche Ursachen hat eine hohe Load Average?

Eine hohe Load Average ist ein Symptom, keine Ursache. Zudem kann dieselbe Zahl aus sehr verschiedenen Problemen entstehen. Auf Servern mit Websites sind vor allem diese Ursachen typisch:

• CPU intensive Arbeit: Dynamische Seiten ohne Cache, schwere PHP Skripte, Bildverarbeitung, Kompression und Suchindizes.
• Wartezeiten bei Festplatten I/O: Langsame oder volle Festplatten, große Backups, starkes Schreiben von Logs und Datenbankabfragen ohne Index.
• Zu wenig Arbeitsspeicher und Swap: Ist der RAM voll, lagert der Kernel Speicherseiten auf die Festplatte aus, was zusätzliche Wartezeiten erzeugt.
• Stau bei PHP-FPM und MySQL: Viele gleichzeitige Anfragen, lange Abfragen und gesperrte Tabellen verlängern die Schlange.
• Bots und Angriffe: Anmeldeversuche per Brute Force oder aggressive Crawler erzeugen Last ohne echte Besucher.
• Wartezeiten durch Virtualisierung: Auf einem VPS können andere virtuelle Maschinen auf demselben Host Rechenzeit beanspruchen.

Steigt die Last in einem Onlineshop zum Beispiel während einer Rabattaktion, steckt vermutlich echter Traffic dahinter. Steigt sie dagegen um Mitternacht, wenn kaum Besucher da sind, werden ein geplantes Backup oder Bots wahrscheinlicher. Für Bots lohnt sich zunächst ein Blick in die Zugriffslogs mit unserer Logfile Analyse.

Wie erkennen Sie, ob die CPU die Last verursacht?

Öffnen Sie zunächst top und sehen Sie sich die Zeile %Cpu(s) oben an. Dort finden Sie Felder wie us (Benutzerprozesse), sy (Kernel), id (Leerlauf), wa (Warten auf I/O) und st (der virtuellen Maschine entzogene Zeit).

Bei CPU bedingter Last sind us oder sy hoch und id niedrig. Außerdem zeigt Ihnen die Taste 1 in top jeden Prozessor in einer eigenen Zeile. Ist ein Kern dauerhaft voll und die übrigen sind frei, bremst womöglich ein Prozess mit nur einem Thread.

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

Dann listet dieser Befehl die fünfzehn Prozesse mit dem höchsten CPU Verbrauch. Stehen dort php-fpm, mysqld oder ein Backupwerkzeug ganz oben, grenzen Sie die Suche entsprechend ein.

Auf einem VPS sollten Sie zudem den Wert st beobachten. Die Manpage zu iostat definiert Steal als den Anteil der Zeit, in dem eine virtuelle CPU unfreiwillig wartete, während der Hypervisor einen anderen virtuellen Prozessor bediente. Bleibt dieser Wert dauerhaft hoch, liegt das Problem in der Aufteilung des Hosts, nicht in Ihrem Code. Dann sprechen Sie besser mit Ihrem Hoster, statt Software zu optimieren.

Wie treiben Wartezeiten bei Festplatten I/O die Load Average nach oben?

Unter Linux geht ein Prozess, der auf die Festplatte wartet, in den nicht unterbrechbaren Schlaf über, also in den Zustand D. Die Load Average zählt auch diese Prozesse. Wird der Speicher langsam, steigt der Wert deshalb selbst bei untätiger CPU. Das ist auf Webservern die häufigste Quelle verwirrender Zahlen.

Prüfen Sie zunächst den Wert wa in top. Danach listen Sie Prozesse im Zustand D auf und holen erweiterte Statistiken pro Laufwerk:

ps -eo stat,pid,user,comm | awk '$1 ~ /^D/'iostat -x 2 5

iostat gehört zum Paket sysstat; fehlt es, installieren Sie sysstat mit dem Paketmanager Ihrer Distribution. Laut Manpage zu iostat zeigt %iowait den Anteil der Zeit, in der die CPU untätig war, während eine Festplattenanfrage offen war. Die Spalten await nennen die mittlere Dauer einer Anfrage in Millisekunden, einschließlich Wartezeit. Zudem zeigt %util, wie viel der Zeit das Gerät beschäftigt war.

Lesen Sie %util allerdings mit Vorsicht. Laut Manpage bedeutet ein Wert nahe 100 Prozent Sättigung bei Geräten, die Anfragen nacheinander abarbeiten. Moderne SSD und NVMe Laufwerke arbeiten parallel; dort heißt ein hoher %util nicht immer Sättigung. Steigende await Werte sind daher das verlässlichere Warnsignal.

Wie erhöhen knapper Arbeitsspeicher und Swap die Serverlast?

Wird der RAM knapp, lagert der Kernel selten genutzte Speicherseiten in den Swap auf der Festplatte aus. Konkret ist Swap ein Sicherheitspuffer, der den Server bei einem plötzlichen Speicherbedarf am Leben hält. Allerdings ist eine Festplatte viel langsamer als RAM. Schreibt und liest das System ständig Seiten hin und her, warten die Prozesse auf die Festplatte, und die Serverlast steigt.

free -hswapon --showvmstat 2 5

free -h zeigt gesamten, belegten und verfügbaren Speicher in lesbaren Einheiten. swapon --show listet die aktiven Swapbereiche. Laut Manpage zu vmstat zeigt si die pro Sekunde von der Festplatte eingelagerte und so die pro Sekunde ausgelagerte Speichermenge.

Entscheidend ist dabei der laufende Swapverkehr, nicht die Größe des Swap. Ist der Swap stark belegt, bleiben si und so aber nahe null, liegen dort nur alte, ungenutzte Seiten; das schadet selten. Bleiben si und so dagegen dauerhaft über null, fehlt dem Server Arbeitsspeicher.

Geht der Speicher ganz aus, kann der OOM Killer des Kernels einen Prozess beenden. Spuren davon finden Sie im Kernellog mit journalctl -k | grep -i "out of memory". Wie Sie Swap in passender Größe anlegen, zeigen wir Schritt für Schritt in unserer Anleitung Swap Datei erstellen und SSH absichern.

Wie treiben PHP und MySQL die Load Average nach oben?

Auf Websites sind PHP-FPM und MySQL die zwei klassischen Lastquellen. PHP-FPM führt jede dynamische Anfrage in einem Kindprozess aus, und die Einstellung pm.max_children begrenzt deren Zahl. Ist die Grenze zu hoch, verbrauchen die parallelen Prozesse den Arbeitsspeicher und drängen den Server in den Swap. Ist sie zu niedrig, stauen sich die Anfragen, und im Log erscheint die Warnung server reached pm.max_children setting.

Bei MySQL kosten langsame Abfragen ohne Index sowohl CPU als auch Festplatte. Laufende Abfragen sehen Sie in MySQL mit SHOW FULL PROCESSLIST;. Für eine dauerhafte Analyse aktivieren Sie das Slow Query Log über die Variablen slow_query_log und long_query_time. Wie Sie das sicher einstellen, zeigt unser Leitfaden MySQL unter Ubuntu installieren und optimieren.

Zudem belastet fehlendes Caching beide Seiten. Prüfen Sie Ihre OPcache Einstellungen, damit PHP Skripte nicht bei jeder Anfrage neu kompiliert. Für wiederkehrende Abfragen und Sitzungsdaten kann Caching mit Redis oder Memcached die Last spürbar senken.

Kurz gesagt brauchen Probleme mit PHP und MySQL selten einen größeren Server. Meist helfen weniger wiederholte Arbeit und bessere Abfragen.

Wie lesen Sie die Ausgabe von vmstat für die Diagnose?

vmstat ist Ihr schnelles Diagnosewerkzeug, denn es fasst CPU, Speicher, Swap und Festplatte in einer Zeile zusammen. Der Befehl vmstat 2 5 gibt fünf Berichte im Abstand von zwei Sekunden aus. Laut Manpage druckt vmstat ohne Verzögerung nur einen Bericht mit Durchschnittswerten seit dem Systemstart. Lesen Sie also nicht die erste Zeile, sondern die folgenden.

Gemäß den Definitionen in der Manpage zu vmstat achten Sie vor allem auf diese Felder:

• r: Zahl der lauffähigen Prozesse, also laufend oder auf Rechenzeit wartend. Liegt sie dauerhaft über der Kernanzahl, hat sich eine CPU Schlange gebildet.
• b: Zahl der Prozesse, die auf den Abschluss von I/O warten. Bleibt sie über null, prüfen Sie die Festplatte.
• si / so: Ein und Auslagerung im Swap. Dauerhafte Werte über null deuten auf Speichermangel.
• wa: Zeit, die mit Warten auf I/O verging.
• st: Zeit, die der virtuellen Maschine entzogen wurde.

So erkennen Sie, welche Komponente die Last speist. Konkret bedeutet ein hohes r bei niedrigem b CPU bedingte Last. Sind dagegen b und wa hoch, stehen Wartezeiten der Festplatte im Vordergrund. Sind dann auch si und so hoch, steckt dahinter höchstwahrscheinlich Speichermangel.

Worauf achten Sie in top und htop?

top ist auf nahezu jedem Linux Server vorhanden. htop bietet eine übersichtlichere, farbige Oberfläche und kommt in den meisten Distributionen als eigenes Paket. Beide zeigen dieselben Grunddaten; nur die Darstellung unterscheidet sich.

Beim Öffnen empfehlen wir diese Reihenfolge:

1. Lastzeile: Die drei Werte und ihr Trend. Vergleichen Sie sie mit der Kernanzahl.
2. CPU Zeile: Die Anteile us, sy, wa und st. Hier unterscheiden Sie zum ersten Mal die Art der Last.
3. Speicher und Swap: Verfügbarer Arbeitsspeicher und Swapnutzung.
4. Prozessliste: Die Prozesse mit dem höchsten CPU oder Speicherverbrauch. In top sortiert die Taste P nach CPU und die Taste M nach Speicher.
5. Statusspalte: Ein D in der Spalte S heißt, dass der Prozess auf die Festplatte wartet.

Allerdings zeigen diese Werkzeuge nur eine Momentaufnahme. Tritt das Problem um drei Uhr nachts auf und Sie schauen um neun Uhr, sehen Sie nichts Brauchbares. Deshalb brauchen Sie ein Monitoring mit Verlauf. Die Datensammlung des Pakets sysstat oder das Monitoring Ihres Hosters schließt diese Lücke.

Was ist PSI und was ergänzt es zur Load Average?

PSI (Pressure Stall Information) ist eine Funktion des Linux Kernels, die den Druck auf einzelne Ressourcen getrennt misst. Die Load Average vermischt CPU und Festplattenwartezeiten in einer Zahl. PSI bietet dagegen eigene Dateien für CPU, Speicher und I/O unter /proc/pressure/.

cat /proc/pressure/cpucat /proc/pressure/memorycat /proc/pressure/io

Laut PSI Dokumentation des Linux Kernels enthält jede Datei zwei Zeilen, some und full. Die Zeile some zeigt den Zeitanteil, in dem zumindest einige Aufgaben an dieser Ressource hängen. Die Zeile full zeigt hingegen den Zeitanteil, in dem alle nicht untätigen Aufgaben gleichzeitig hängen. Zudem stehen die Felder avg10, avg60 und avg300 für Fenster von 10, 60 und 300 Sekunden.

In der Praxis ist der Nutzen einfach. Ist die Last hoch, sagt PSI Ihnen direkt, welche Ressource knapp ist. Zeigt zum Beispiel io hohe Werte und cpu niedrige, liegt das Problem im Speichersystem, nicht im Prozessor.

Diese Dateien gibt es allerdings nicht auf jedem System; Kernelversion und Konfiguration entscheiden darüber. Fehlen sie, treffen Sie dieselbe Unterscheidung mit vmstat und iostat.

Wo sehen Sie die Serverlast in cPanel und WHM?

Haben Sie auf Ihrem eigenen Server Zugriff auf WHM, sehen Sie die Serverlast auch ohne Terminal. Die Dokumentation von cPanel zur Seite Service Status beschreibt, dass der Bereich System Information die Last des Servers, den belegten Arbeitsspeicher, den belegten Swap und den jeweiligen Status auflistet.

Dieselbe Seite erklärt auch die Statussymbole. Ein Häkchen heißt, dass Sie weniger als 80 Prozent der Ressource nutzen. Ein Warndreieck steht für 80 bis 89 Prozent, ein X für 90 Prozent oder mehr. Diese Schwellen gehören zur Anzeige von cPanel; sie sind keine allgemeine Linux Regel.

Beim Shared Hosting ist die Lage allerdings anders. Als Nutzer von cPanel spiegelt die Gesamtlast des Servers nicht Ihre eigene Website wider, denn auf derselben Maschine laufen weitere Konten. Manche Anbieter setzen Grenzen pro Konto und zeigen in cPanel eine Übersicht zur Ressourcennutzung Ihres Kontos. Wie die Isolierung der Konten funktioniert, erklären wir im Beitrag zu CageFS und Kontoisolierung im Shared Hosting.

Beim Shared Hosting versuchen Sie also nicht, die Serverlast selbst zu senken. Stattdessen prüfen Sie, ob Ihr eigenes Konto an seine Grenzen stößt.

Wann ist eine hohe Load Average wirklich ein Problem?

Eine hohe Load Average ist nicht immer ein Notfall. Ein nächtliches Backup kann den Wert für einige Minuten anheben; bemerken die Nutzer nichts, ist das normale Arbeit. Echte Probleme erkennen Sie an diesen Zeichen:

• Der Wert für 15 Minuten bleibt über Stunden oder Tage deutlich über der Kernanzahl.
• Antwortzeiten steigen, das Backend reagiert träge, oder es kommt zu Zeitüberschreitungen.
• Besucher sehen gelegentlich Fehler 502 oder 503.
• Der Swapverkehr bleibt hoch, oder das Kernellog meldet Speichermangel.
• Die Last steigt zu Zeiten, die sich nicht mit Traffic erklären lassen.

Unter starker Last erreicht PHP-FPM zum Beispiel seine Prozessgrenze, und der Webserver weist neue Anfragen ab. Besucher sehen dann eine Fehlerseite. Die Diagnose dieses Fehlers beschreiben wir im Beitrag zum Fehler 503 Service Unavailable.

Anders gesagt lautet die Frage nicht "ist die Zahl hoch?", sondern "leiden Nutzererlebnis und Verfügbarkeit?".

Wie hängen Load Average und eine langsame Website zusammen?

Ist die Serverlast hoch, wartet jede Anfrage auf Prozessor oder Festplatte. Diese Wartezeit verlängert die Zeit bis zum ersten Byte. Folglich warten Besucher länger, bis die Seite erscheint. Hohe Last gehört somit zu den direkten Ursachen einer langsamen Website.

Der Zusammenhang gilt allerdings nur in eine Richtung. Ist die Website langsam, die Last aber niedrig, liegt die Ursache vermutlich woanders. Große Bilder, schweres JavaScript, eine langsame externe API oder DNS Verzögerungen tauchen in diesem Wert nicht auf. Die ganze Liste serverseitiger Ursachen finden Sie in unserem Beitrag Warum ist meine Website langsam.

Zudem trifft Langsamkeit nicht nur Besucher. Ein träge antwortender Server lässt auch die Crawler von Suchmaschinen warten.

Lesen Sie daher zwei Messungen nebeneinander: die Load Average auf dem Server und die echte Ladezeit beim Nutzer. Ist eine hoch und die andere normal, erkennen Sie schnell, in welcher Schicht das Problem liegt.

In welcher Reihenfolge beheben Sie eine hohe Serverlast?

In der Hektik liegt ein Neustart nahe. Ein Neustart beseitigt jedoch nicht die Ursache, und er löscht zudem die Daten, die Sie für die Diagnose brauchen. Wir empfehlen stattdessen diese Reihenfolge:

1. Zustand sichern: Speichern Sie die Ausgabe von uptime, top, vmstat 2 5 und free -h in einer Datei.
2. Art bestimmen: CPU, Festplatte oder Speicher? Die Werte us, wa, si/so und b weisen den Weg.
3. Prozess finden: Ermitteln Sie den Prozess hinter der Last und seinen Besitzer, etwa eine Website, einen Benutzer oder einen Cronjob.
4. Traffic prüfen: Suchen Sie in den Zugriffslogs nach Spitzen, Bots oder Brute Force Versuchen.
5. Kurzfristig entlasten: Verschieben Sie unnötige Cronjobs, blockieren Sie feindlichen Traffic und prüfen Sie hängende Abfragen.
6. Dauerhaft lösen: Caching, bessere Abfragen, angepasste Einstellungen für PHP-FPM oder mehr Ressourcen.

Erzeugen etwa Brute Force Versuche auf Ihre Anmeldeseite die Last, blockiert Fail2ban sie auf Serverebene. Mehr Hardware heben Sie sich für den Schluss auf. Wer ein Softwareproblem mit einem größeren Server zudeckt, zahlt mehr, und das Problem kehrt meist zurück.

Wann überlassen Sie das Problem besser Ihrem Hoster?

Ehrlich gesagt müssen Sie nicht jedes Lastproblem selbst lösen. In manchen Fällen ist ein Ticket beim Support Ihres Hosters der richtige Schritt:

• Sie nutzen Shared Hosting, und die Last ist auf dem ganzen Server hoch; das liegt außerhalb Ihrer Kontrolle.
• Der Wert st auf Ihrem VPS bleibt hoch; die Aufteilung des physischen Hosts ist Sache des Anbieters.
• Die Latenz der Festplatte wirkt hardwarebedingt, oder das Kernellog meldet Festplattenfehler.
• Sie haben einen Managed Service gebucht; Änderungen an der Serverkonfiguration gehören dann zu dieser Leistung.
• Sie haben keinen Zugriff als root, oder Sie fühlen sich auf der Kommandozeile unsicher.

Legen Sie dem Ticket außerdem Belege bei. Die Uhrzeit des Problembeginns, die Ausgabe von uptime und vmstat, die betroffene Adresse und Ihre letzten Änderungen beschleunigen die Arbeit des Supports erheblich. So wird aus "meine Seite ist langsam" eine messbare technische Meldung.

Stoßen Sie regelmäßig an Kapazitätsgrenzen, prüfen Sie auch, ob Ihr Tarif noch passt. Die Kriterien dafür nennen wir im Leitfaden Webhosting auswählen.

Wie machen Sie das Beobachten der Load Average zur Gewohnheit?

Die beste Diagnose beginnt, bevor etwas ausfällt: Sie kennen den Normalzustand Ihres Servers. Beobachten Sie die Last deshalb nicht nur in der Krise, sondern auch in ruhigen Phasen. Kennen Sie eine normale Woche, fällt Ihnen ein ungewöhnlicher Morgen sofort auf.

Konkret sieht eine praktische Routine etwa so aus. Notieren Sie einmal pro Woche die Ausgabe von uptime und vmstat. Prüfen Sie die Werte vor und nach Kampagnen oder Hochphasen. Schauen Sie außerdem nach größeren Updates von Plugins oder Themes erneut hin. Legen Sie dann in Ihrem Monitoring eine Warnschwelle fest, die sich an der Kernanzahl orientiert.

Ein großer Teil der Last stammt von der Website selbst: Seiten ohne Cache, unnötige Plugins und nicht optimierte Abfragen. Unser Team plant diese Punkte in Projekten für Webdesign und Entwicklung von Anfang an ein. Somit bedient die Website auf demselben Server mehr Besucher mit weniger Ressourcen.

Zusammengefasst ist die Load Average der Puls Ihres Servers. Sie stellt allein keine Diagnose, hilft Ihnen aber, die richtige Frage zu stellen: Warum ist die Schlange gewachsen, und welche Ressource ist knapp?