Server-Load 120 auf dem vServer: Eine echte Fehlersuche in vier Schritten

Load Average 120 auf einem 12-vCPU-Server, der komplette Webserver-Stack mit null laufenden Prozessen, eine Datenbank, die fast keinen Arbeitsspeicher nutzen durfte – und am Ende war die eigentliche Ursache etwas ganz anderes, als alle vier vorherigen Symptome vermuten ließen. Dieser Artikel dokumentiert eine reale Fehlersuche auf einem cPanel-vServer mit mehreren WordPress-Seiten, Schritt für Schritt, mit allen Befehlen zum Selbst-Nachprüfen.

Kurz erklärt: Was ist „Load“ überhaupt?

Die Load (oder „Load Average“) zeigt an, wie viele Prozesse auf eurem Server gerade Rechenzeit haben wollen – egal ob sie sie bekommen oder warten müssen. Ein Server mit 12 CPU-Kernen kann etwa 12 Prozesse gleichzeitig wirklich ausführen. Zeigt euch uptime eine Load von 20, wollen fast doppelt so viele Prozesse gleichzeitig rechnen, wie physisch möglich ist – der Rest wartet in der Schlange. Alles unter der Kernzahl ist entspannt, deutlich darüber ein Alarmsignal. Wie man Load-Werte richtig einordnet und wovon sie tatsächlich abhängen, zeigt auch unsere detaillierte Analyse eines Load-Average-20-Falls mit strace und WP-CLI profile.

Der Ausgangspunkt

Der Betreiber meldete: Server-Load 120, „lauter hängende PHP-Prozesse“, und hatte bereits versucht, nginx zu stoppen und PHP-FPM neu zu starten. Genau dieser Impuls – irgendwas neu starten, bis es besser wird – ist verständlich, verschleiert aber oft die eigentliche Ursache. Also: erst Diagnose, dann Handeln.

Ursache 1: Der komplette Webserver war down

Der erste Blick in die Prozessliste zeigte etwas Überraschendes: Sowohl nginx als auch Apache liefen mit null aktiven Prozessen. Nicht „langsam“ – komplett offline. Nur ein einziger PHP-FPM-Prozess war noch am Leben.

Was das für euch bedeutet: Bevor ihr euch in Detailanalysen stürzt, prüft immer zuerst die Basics:

systemctl status nginx httpd

Ein Server, der „hoch belastet“ wirkt, aber eigentlich gar keine Anfragen mehr annimmt, sieht in Monitoring-Tools manchmal genauso aus wie ein überlasteter – nur dass hier gar nichts mehr lief. Nach dem Neustart beider Dienste kam die Seite zurück.

Ursache 2: Alle PHP-FPM-Pools hatten denselben Wert – egal wie viel Traffic sie hatten

Der Server betrieb acht verschiedene WordPress-Seiten, jede mit sehr unterschiedlichem Besucheraufkommen – von der Flaggschiff-Newsseite mit hunderten täglichen Zugriffen bis zu ruhigen Nebenprojekten. Bei der Prüfung der PHP-FPM-Konfiguration (das ist der Prozess-Manager, der PHP-Anfragen für WordPress abarbeitet) zeigte sich: jede einzelne der neun Domains hatte identisch pm.max_children = 40 eingestellt – der reine cPanel-Standardwert, unverändert übernommen, ohne jemals angepasst worden zu sein.

Klingt erstmal harmlos – 40 Prozesse pro Domain wirkt moderat. Das Problem: 40 × 9 Domains = 360 theoretisch gleichzeitig mögliche PHP-Prozesse. Bei einem gemessenen Speicherbedarf von rund 150 MB pro Prozess wären das im Extremfall über 50 GB RAM – mehr, als der Server überhaupt hatte. Es reichte, dass mehrere Domains gleichzeitig etwas mehr Besucher bekamen (zum Beispiel durch einen Suchmaschinen-Crawler, der die ganze Domain-Sammlung gleichzeitig abklapperte), damit Speicher und Datenbankverbindungen knapp wurden.

Die Lösung war keine pauschale Erhöhung, sondern eine Staffelung nach tatsächlichem Traffic – die stark frequentierte Domain bekam mehr Spielraum (16), ruhige Domains deutlich weniger (6–8). In Summe kamen wir von 360 theoretisch möglichen auf 74 real sinnvolle Prozesse – komfortabel im Speicherbudget, aber ohne unnötige Verschwendung.

Praxis-Tipp für eure eigene Seite: Wenn ihr mehrere Domains auf einem Server betreibt (egal ob cPanel, Plesk oder selbst verwaltet), lohnt sich ein Blick, ob wirklich jede Domain dieselbe Pool-Größe verdient. Eine kaum besuchte Nebenseite braucht keine 40 gleichzeitigen PHP-Prozesse. Wie viel CPU-Leistung so ein Setup insgesamt braucht, hängt auch stark von der Server-Hardware ab – unser VPS-Benchmark zu vCPU-Anzahl vs. Kerngeschwindigkeit geht darauf im Detail ein.

Ursache 3: Die Datenbank durfte fast keinen Arbeitsspeicher nutzen

Der zweite Blick ging auf MariaDB (die Datenbank hinter WordPress). Hier zeigte sich ein Wert, der uns kurz stutzen ließ: innodb_buffer_pool_size – also der Speicher, den die Datenbank für häufig gebrauchte Daten im RAM vorhalten darf, statt jedes Mal von der Festplatte zu lesen – stand auf gerade einmal 121 MB. Bei einem Server mit 46 GB RAM.

Die Ursache war eine klassische Config-Kollision: In der Haupt-Konfigurationsdatei stand versehentlich (vermutlich aus einem generischen Sicherheits-Hardening-Snippet übernommen) eine hartcodierte Zeile, die einen früher gesetzten, deutlich sinnvolleren Wert überschrieb. Zusätzlich lief bereits ein automatisches Datenbank-Tuning-Tool auf dem Server, dessen Empfehlung (rund 4,2 GB, passend zur tatsächlichen Datenbankgröße) seit Monaten unbestätigt herumlag, statt angewendet zu werden.

Praxis-Tipp: Wenn ihr ein Tuning-Tool wie Releem, MySQLTuner oder ähnliches einsetzt – schaut regelmäßig nach, ob Empfehlungen tatsächlich aktiv sind, nicht nur vorgeschlagen. Ein guter Vorschlag, der nie angewendet wird, bringt niemandem etwas.

Ursache 4: Der eigentliche Übeltäter – ein Server, der sich selbst bombardierte

Nach den ersten drei Korrekturen war der Server deutlich ruhiger – bis die Last erneut anzog, diesmal konzentriert auf CPU statt auf Arbeitsspeicher. Ein Blick in die Zugriffsprotokolle einer der Domains brachte den eigentlichen Auslöser der gesamten Krise ans Licht:

Über 278.000 Anfragen an nur eine einzige Domain kamen von der eigenen Server-IP – mit einem Nutzeragenten, der ihn eindeutig als mod_pagespeed-Modul auswies. Zum Vergleich: Die Seite hatte an diesem Tag insgesamt rund 800 echte Besucher-Zugriffe. Das Verhältnis lag bei über 300:1.

Was war passiert? mod_pagespeed ist ein (mittlerweile von Google eingestelltes und nicht mehr gepflegtes) Apache-Modul, das Webseiten automatisch optimiert – Bilder verkleinern, CSS/JS zusammenfassen und minifizieren. Damit das nicht bei jedem Seitenaufruf neu passieren muss, legt es die optimierten Dateien in einem Cache-Verzeichnis ab. Auf diesem Server existierte das konfigurierte Cache-Verzeichnis schlicht nicht mehr – vermutlich bei einer früheren Server-Migration verloren gegangen. Ohne funktionierenden Cache verarbeitete das Modul bei jedem einzelnen Seitenaufruf sämtliche Bilder, Skripte und Stylesheets komplett neu – und holte sich dafür jede einzelne Ressource per HTTP-Anfrage selbst noch einmal, über den ganz normalen WordPress-Stack.

Interessant: Eine der acht Domains war komplett unbetroffen – weil der Betreiber dort schon vor längerer Zeit, offenbar wegen genau dieses Problems, das Modul für diese eine Seite manuell abgeschaltet hatte. Nur wusste er selbst nicht mehr, dass es der Grund war, und die anderen sieben Domains liefen weiterhin ungeschützt mit.

Die Lösung: Modul serverweit deaktivieren. Kein Neustart nötig, keine Downtime. Die Last fiel innerhalb weniger Minuten von einem Wert weit über der Kernzahl auf einen entspannten Bruchteil davon.

Praxis-Tipp – das ist der wichtigste Punkt dieses Artikels: Wenn eure Serverlast unerklärlich hoch ist, schaut nicht nur auf wie viele Anfragen reinkommen, sondern woher. Ein Blick in die Zugriffsprotokolle nach den häufigsten IP-Adressen deckt oft mehr auf als jede reine Ressourcen-Metrik:

tail -300 /pfad/zu/eurem/access-log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Wenn dort die eigene Server-IP mit auffällig vielen Treffern auftaucht, lohnt sich ein zweiter Blick auf den Nutzeragenten in derselben Zeile – oft verrät er sofort, welcher Dienst sich selbst überlastet.

Die Checkliste zum Nachprüfen auf eurem eigenen Server

• Läuft überhaupt alles? systemctl status nginx apache2 httpd php-fpm (Namen je nach System) – klingt banal, ist aber der häufigste übersehene erste Check
• Sind PHP-FPM-Pools nach Traffic gestaffelt, oder haben alle eurer Domains denselben Standardwert? Bei mehreren Seiten auf einem Server: pm.max_children je Domain gegen tatsächlichen Traffic prüfen, nicht pauschal hochsetzen
• Ist der Datenbank-Buffer-Pool sinnvoll dimensioniert? Bei MySQL/MariaDB: SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; – sollte einen relevanten Anteil des verfügbaren RAMs ausmachen, nicht ein paar hundert MB auf einer 32-GB-Box
• Fragt sich euer Server selbst an? Zugriffsprotokolle nach der eigenen Server-IP durchsuchen – alte, ungepflegte Optimierungs-Module (mod_pagespeed und Ähnliches) sind ein häufiger, unterschätzter Übeltäter
• Alte Konfigurationsreste prüfen: Wenn mehrere Config-Dateien dieselbe Einstellung setzen, gewinnt oft die zuletzt gelesene – nicht zwingend die sinnvollste

Wer eine strukturierte, vollständige Vorgehensweise für die eigene Seite sucht, statt nur diesen einen Fall nachzuvollziehen, findet einen Gesamtüberblick in unserem Leitfaden zur WordPress Performance-Optimierung.

---

Häufige Fragen

Warum war die Last trotz freiem RAM so hoch?
Weil nicht jeder Engpass ein Speicherproblem ist. In diesem Fall war zeitweise reichlich RAM frei, aber alle CPU-Kerne waren durch die Selbstanfragen-Kaskade ausgelastet – RAM- und CPU-Engpässe brauchen unterschiedliche Diagnosen und unterschiedliche Lösungen.

Reicht es, den Server einfach neu zu starten?
Ein Neustart lindert das akute Symptom oft kurzfristig, behebt aber selten die Ursache. In diesem Fall hätte ein reiner Neustart die Krise nur um Stunden verschoben, bis die Selbstanfragen-Kaskade wieder Fahrt aufgenommen hätte.

Muss ich mod_pagespeed grundsätzlich meiden?
Das Modul wird von Google seit Jahren nicht mehr weiterentwickelt. Auf modernen Setups (insbesondere mit einem CDN oder Cloudflare davor) übernehmen meist ohnehin andere Werkzeuge die Optimierung. Wer es noch aktiv nutzt, sollte zumindest sicherstellen, dass das Cache-Verzeichnis existiert und beschreibbar ist – sonst passiert genau das hier beschriebene Szenario.

---

Autor: Manuel Kuhn, WordPress Performance Engineer & Linux-Serveradministrator, Hosting-Fixers.de – September 2026