Linux-Server plötzlich überlastet: Ursachen systematisch finden und beheben

Ein Linux-Server läuft über Monate stabil – und ist plötzlich kaum noch erreichbar. Webseiten laden nur noch langsam, PHP-Anfragen bleiben hängen und im schlimmsten Fall reagiert selbst der administrative Zugriff über SSH nur noch verzögert.

Gerade bei WordPress-/WooCommerce-Servern kann eine solche Überlastung unerwartet auftreten. Die Ursache muss dabei weder ein klassischer Hackerangriff noch ein sprunghafter Anstieg realer Besucher sein. Manchmal genügt ein bisher unauffälliger Endpunkt, dessen Aufruf außergewöhnlich viel Rechenleistung benötigt.

In diesem Praxisbeispiel verursachte die Produktübersicht eines WooCommerce-Auktionssystems eine massive Serverlast. Die Seite musste Daten zu mehr als 16.000 Produkten beziehungsweise Auktionen verarbeiten. Ein externer Crawler rief diesen ressourcenintensiven Endpunkt in kurzer Zeit sehr häufig auf – verteilt über zahlreiche unterschiedliche IP-Adressen.

Der Fall zeigt, wie sich eine plötzlich hohe Server-Auslastung erkennen, historisch untersuchen, richtig beurteilen und gezielt beseitigen lässt.

Die Ausgangslage: Ein WooCommerce-Server reagiert nicht mehr

Der betroffene Linux-Server betrieb eine umfangreiche WordPress-/WooCommerce-Anwendung. Neben den üblichen Shop-Funktionen enthielt das System zahlreiche Auktionen. Eine bestimmte Produktübersicht konnte mehr als 16.000 Einträge auf einmal darstellen.

Solange diese Seite nur gelegentlich aufgerufen wurde, blieb das Problem weitgehend unbemerkt. Jeder einzelne Aufruf löste jedoch umfangreiche Verarbeitungsschritte aus:

• WordPress musste die Anfrage entgegennehmen und verarbeiten.
• WooCommerce ermittelte die relevanten Produkte.
• PHP-FPM führte den Anwendungscode aus.
• MySQL beziehungsweise MariaDB musste große Datenmengen abfragen und sortieren.
• Anschließend wurde eine entsprechend umfangreiche HTML-Antwort erzeugt.

Ein einzelner Aufruf war für den Server noch zu bewältigen. Viele unmittelbar aufeinanderfolgende Aufrufe führten jedoch dazu, dass PHP- und Datenbankprozesse immer mehr Rechenzeit beanspruchten. Schließlich waren kaum noch Ressourcen für reguläre Besucher oder administrative Zugriffe verfügbar.

Das eigentliche Problem war daher nicht nur die Zahl der Anfragen. Entscheidend waren die Kosten jeder einzelnen Anfrage.

Alarmierung über Grafana und Telegram

Eine Serverüberlastung sollte möglichst erkannt werden, bevor Kunden oder Mitarbeiter den Ausfall melden. Im vorliegenden Fall erfolgte die Alarmierung über das Server-Monitoring in Grafana. Die Benachrichtigung wurde unmittelbar über Telegram versendet.

Grafana kann Warnungen über sogenannte Kontaktpunkte an Telegram übergeben. Dadurch erhält der zuständige Administrator eine Meldung, sobald eine definierte Schwelle überschritten wird. Die offizielle Grafana-Dokumentation beschreibt Telegram als direkt unterstützte Benachrichtigungsintegration.

Typische Alarmkriterien sind:

• ungewöhnlich hohe CPU-Auslastung,
• hohe Systemlast,
• knapper Arbeitsspeicher,
• starke I/O-Auslastung,
• viele gleichzeitig aktive PHP-FPM-Prozesse,
• erhöhte Antwortzeiten,
• nicht mehr erreichbare Dienste,
• steigende PSI-Werte.

Die Alarmierung ist jedoch nur der Anfang. Eine Warnung wie „CPU-Auslastung über 90 Prozent“ sagt noch nicht, ob der Server tatsächlich überlastet ist und wodurch die Last verursacht wird.

Im folgenden Beispiel erzeugen wir mit stress-ng -cpu 8 künstlichen Stress, mit dem wir alle CPU’s auslasten. Der Webserver und die dazugehörigen php-fpm-Prozesse bleiben aber nach wie vor erreichbar (siehe „Avg. Response Time“), der PSI bleibt bei ca. 20.

Warum die CPU-Auslastung allein nicht ausreicht

Eine CPU-Auslastung von 90 oder sogar 100 Prozent wirkt zunächst alarmierend. Sie muss aber nicht zwangsläufig ein Problem darstellen.

Ein Server darf seine vorhandene Rechenleistung nutzen. Wenn die Prozesse ihre Arbeit weiterhin zeitnah erledigen, die Antwortzeiten stabil bleiben und keine Warteschlangen entstehen, kann eine hohe CPU-Auslastung durchaus akzeptabel sein.

Kritisch wird es, wenn gleichzeitig ein hoher Ressourcendruck entsteht. Hier kommt PSI – Pressure Stall Information – ins Spiel.

PSI zeigt, wie lange Prozesse nicht weiterarbeiten konnten, weil eine benötigte Ressource nicht verfügbar war. Linux unterscheidet dabei insbesondere zwischen:

• CPU-Druck,
• Speicherdruck,
• I/O-Druck.

Die Linux-Kernel-Dokumentation zu PSI beschreibt genau dieses Problem: Bei umkämpften CPU-, Speicher- oder I/O-Ressourcen entstehen Latenzspitzen, Durchsatzverluste und im Extremfall Speicherabbrüche.

Vereinfacht gesagt:

CPU-Auslastung zeigt, wie stark eine Ressource verwendet wird. PSI zeigt, ob Prozesse bereits auf diese Ressource warten müssen.

Eine hohe CPU-Auslastung bei niedrigen PSI-Werten kann bedeuten, dass der Server intensiv, aber noch kontrolliert arbeitet. Steigen CPU-Auslastung und CPU-PSI gleichzeitig stark an, können Prozesse nicht mehr zeitnah abgearbeitet werden. Es bilden sich Warteschlangen und der Server reagiert zunehmend langsamer.

Im konkreten Fall war deshalb nicht die hohe CPU-Auslastung allein ausschlaggebend. Erst zusammen mit den stark erhöhten PSI-Werten wurde erkennbar, dass der Server seine Aufgaben nicht mehr bewältigen konnte. Zu diesem Zeitpunkt war auch die Webseite zeitweise nicht mehr erreichbar.

Historische Prozessanalyse mit Atop

Wenn ein Administrator erst einige Minuten nach der Warnung auf den Server zugreift, kann die eigentliche Lastspitze bereits vorüber sein. Werkzeuge wie top oder htop zeigen in erster Linie den aktuellen Zustand. Für eine nachträgliche Ursachenanalyse reicht das häufig nicht aus.

Hier ist Atop besonders hilfreich.

Atop zeichnet die System- und Prozessaktivitäten in regelmäßigen Abständen auf. Dadurch lässt sich später rekonstruieren:

• welche Prozesse aktiv waren,
• wie viel CPU-Zeit sie verbrauchten,
• wie viel Arbeitsspeicher sie belegten,
• welche Datenträgerzugriffe stattfanden,
• wie stark das Netzwerk beansprucht wurde,
• welche Prozesse neu gestartet oder beendet wurden.

Im untersuchten Zeitraum zeigte Atop eine auffällig hohe Aktivität von PHP-FPM und MySQL beziehungsweise MariaDB. Das war ein wichtiger Hinweis: Die Überlastung entstand nicht durch einen beliebigen Systemprozess, sondern innerhalb der Webanwendung und ihrer Datenbankzugriffe.

Die Atop-Auswertung beantwortete damit die Frage, welche Komponenten den Server belasteten. Sie erklärte aber noch nicht, welche HTTP-Anfragen diese Prozesse ausgelöst hatten.

Mit atop kann man auch regelmässige Snapshots des aktuellen Serverzustandes erstellen. Damit sind detailierte Auswertungen des Servers und der einzelnen Prozesse auch im Nachhinein möglich.

Analyse der Nginx-Logfiles

Der nächste Schritt war deshalb die Untersuchung der Nginx-Zugriffsprotokolle. Sie enthalten je nach Protokollformat unter anderem:

• Zeitpunkt der Anfrage,
• aufgerufene URL,
• HTTP-Methode,
• Statuscode,
• übertragene Datenmenge,
• IP-Adresse des Clients,
• Referrer,
• User-Agent,
• Bearbeitungsdauer.

Zunächst wurden die Zugriffe im Zeitraum der Grafana-Warnung isoliert. Anschließend ließen sich besonders häufig aufgerufene URLs, auffällige User-Agents und ungewöhnlich langsame Anfragen vergleichen.

Eine einfache Häufigkeitsanalyse der angeforderten URLs kann beispielsweise so aussehen:

awk '{print $7}' /var/log/nginx/access.log \
  | sort \
  | uniq -c \
  | sort -nr \
  | head -30

Die genaue Position der URL hängt vom verwendeten Nginx-Protokollformat ab. Bei komprimierten oder rotierten Dateien muss die Abfrage entsprechend angepasst werden.

Im konkreten Fall fiel eine WooCommerce-Produktübersicht auf. Dieser Endpunkt wurde in kurzer Zeit sehr häufig aufgerufen. Da er Informationen zu mehr als 16.000 Auktionen verarbeitete, verursachte jeder Aufruf umfangreiche PHP- und Datenbankarbeit.

Kein klassischer Angriff – aber die Wirkung war vergleichbar

Die Anfragen stammten von einem Crawler aus dem Umfeld von Facebook beziehungsweise Meta. Solche Crawler rufen Webseiten beispielsweise auf, um Linkvorschauen und Metadaten für geteilte Inhalte zu erzeugen. Meta dokumentiert die verwendeten Kennungen in seiner Übersicht über Meta Web Crawlers.

Die Zugriffe müssen deshalb nicht in schädlicher Absicht erfolgt sein. Für die Verfügbarkeit des Servers ist die Motivation des Clients allerdings zweitrangig: Wenn automatisierte Anfragen einen teuren Endpunkt so häufig aufrufen, dass reguläre Nutzer die Anwendung nicht mehr erreichen können, muss der Server geschützt werden.

Die Wirkung entsprach in diesem Fall einem anwendungsbezogenen Denial-of-Service:

1. Ein öffentlich zugänglicher Endpunkt war ungewöhnlich ressourcenintensiv.
2. Der Endpunkt wurde automatisiert und häufig aufgerufen.
3. PHP-FPM und MySQL verbrauchten dadurch fast alle verfügbaren Ressourcen.
4. Andere Anfragen mussten warten oder konnten nicht mehr bearbeitet werden.
5. Der WordPress-/WooCommerce-Server war zeitweise nicht erreichbar.

Warum das vorhandene Standard-Rate-Limit nicht griff

Auf dem Server war bereits eine Begrenzung der Anfragerate eingerichtet. Diese arbeitete jedoch IP-basiert.

Ein übliches Nginx-Rate-Limit verwendet die Client-IP als Schlüssel. Jede IP-Adresse erhält damit einen eigenen Zähler. Überschreitet eine einzelne Adresse das definierte Limit, werden ihre weiteren Anfragen verzögert oder abgewiesen.

In diesem Fall kamen die Zugriffe jedoch von vielen verschiedenen IP-Adressen. Jede einzelne IP blieb unterhalb des Grenzwerts. In Summe erzeugten alle Adressen dennoch eine viel zu hohe Zahl teurer Anfragen.

Das vorhandene Rate-Limit funktionierte technisch korrekt – es verwendete lediglich einen Schlüssel, der nicht zum tatsächlichen Zugriffsmuster passte.

Das ist ein wichtiger Grundsatz für den Betrieb öffentlich erreichbarer Anwendungen:

Ein Rate-Limit ist nur so wirksam wie das Merkmal, nach dem die Anfragen gruppiert werden.

Bei verteilten Crawlern oder Botnetzen genügt eine rein IP-basierte Begrenzung deshalb nicht immer.

Die Lösung: Endpunkt und Herkunft gemeinsam begrenzen

Der problematische WooCommerce-Endpunkt durfte nicht vollständig gesperrt werden. Gleichzeitig sollten reguläre Besucher nicht unter einer allgemeinen Begrenzung leiden.

Die Lösung bestand deshalb aus einem gezielten Nginx-Rate-Limit, das zwei Merkmale kombinierte:

• den ressourcenintensiven Endpunkt,
• die Kennung des verursachenden Crawlers.

Alle passenden Crawler-Anfragen wurden dabei demselben Begrenzungsschlüssel zugeordnet – unabhängig von ihrer IP-Adresse. Die verteilten Zugriffe wurden dadurch als eine gemeinsame Quelle behandelt.

Ein vereinfachtes Konfigurationsbeispiel könnte folgendermaßen aussehen:

map "$uri:$http_user_agent" $auction_crawler_key {
    default "";

    ~*^/produktuebersicht/.*:(facebookexternalhit|meta-externalagent)
        "woocommerce-meta-crawler";
}

limit_req_zone $auction_crawler_key
    zone=woocommerce_meta:10m
    rate=2r/s;

Im betreffenden server– oder location-Block wird die Zone anschließend angewendet:

location / {
    limit_req zone=woocommerce_meta burst=5 nodelay;
    limit_req_status 429;

    try_files $uri $uri/ /index.php?$args;
}

Die Nginx-Direktive limit_req_zone kann Anfragen anhand eines frei definierten Schlüssels zusammenfassen. Laut offizieller Nginx-Dokumentation muss der Schlüssel nicht zwingend die IP-Adresse sein.

Da der Schlüssel im Beispiel für alle anderen Anfragen leer bleibt, werden nur die zuvor ausgewählten Zugriffe erfasst. Die konkreten Grenzwerte müssen allerdings an die Anwendung angepasst und unter realer Last getestet werden.

Wichtig: Ein User-Agent ist keine sichere Identitätsprüfung. Er kann von beliebigen Clients nachgeahmt werden. Für ein gezieltes Lastmanagement ist er dennoch ein brauchbares Klassifizierungsmerkmal. Wenn eine verlässliche Herkunftsprüfung erforderlich ist, müssen zusätzlich andere Merkmale oder vorgelagerte Schutzsysteme verwendet werden.

Rate-Limit zunächst kontrolliert testen

Eine neue Begrenzung sollte nicht unkontrolliert auf einem Produktivsystem aktiviert werden. Andernfalls könnten legitime Anfragen blockiert oder wichtige Funktionen beeinträchtigt werden.

Nginx unterstützt hierfür einen Testbetrieb:

limit_req_dry_run on;

In diesem Modus protokolliert Nginx, welche Anfragen begrenzt worden wären, ohne sie tatsächlich abzulehnen. Damit lässt sich prüfen:

• ob der richtige Endpunkt erkannt wird,
• ob der reguläre Besucherverkehr unbeeinträchtigt bleibt,
• welcher Grenzwert realistisch ist,
• wie groß der erlaubte kurzfristige Anfragepuffer sein sollte.

Nach der Aktivierung sollte außerdem kontrolliert werden, ob die Zahl der Antworten mit dem Statuscode 429 Too Many Requests plausibel ist und ob Facebook beziehungsweise Meta weiterhin notwendige Linkvorschauen abrufen kann.

Vor dem Neuladen der Konfiguration empfiehlt sich immer eine Syntaxprüfung:

nginx -t

Erst danach sollte Nginx kontrolliert neu geladen werden:

systemctl reload nginx

Warum mehr Serverleistung das Grundproblem nicht gelöst hätte

Eine naheliegende Reaktion wäre gewesen, den Server mit mehr CPU-Kernen oder Arbeitsspeicher auszustatten. Das hätte die Auswirkungen möglicherweise vorübergehend reduziert, aber die Ursache nicht beseitigt.

Solange ein öffentlich erreichbarer Endpunkt sehr große Datenmengen verarbeitet und beliebig oft aufgerufen werden kann, wächst die benötigte Leistung mit der Zahl der Anfragen. Ein größerer Server verschiebt dann lediglich den Zeitpunkt der nächsten Überlastung.

Nachhaltiger ist eine Kombination aus mehreren Maßnahmen:

1. Teure Endpunkte identifizieren: Welche URLs erzeugen besonders lange PHP- oder Datenbanklaufzeiten?
2. Ausgabemengen begrenzen: Müssen tatsächlich mehr als 16.000 Produkte auf einer Seite angezeigt werden?
3. Pagination einsetzen: Große Ergebnismengen sollten seitenweise geladen werden.
4. Datenbankabfragen optimieren: Fehlende Indizes oder ineffiziente Abfragen erhöhen die Kosten jedes Aufrufs.
5. Caching prüfen: Geeignete Antworten können teilweise zwischengespeichert werden.
6. Crawler steuern: Nicht jeder automatisierte Client benötigt unbegrenzten Zugriff.
7. Rate-Limits an das Angriffsmuster anpassen: Neben der IP können Endpunkt, User-Agent, Hostname oder andere Merkmale einbezogen werden.
8. Monitoring um PSI und Antwortzeiten ergänzen: CPU-Werte allein zeigen nicht die tatsächliche Auswirkung auf die Anwendung.

Was KMU aus diesem Fall lernen können

Viele kleine und mittlere Unternehmen betreiben geschäftskritische Linux-Systeme, ohne einen eigenen Linux-Administrator zu beschäftigen. Der Server wird einmal eingerichtet und läuft im Normalbetrieb zuverlässig. Probleme entstehen oft erst, wenn sich Zugriffsverhalten, Datenmenge oder Anwendung ändern.

Gerade WordPress- und WooCommerce-Systeme entwickeln im Lauf der Zeit neue Belastungsprofile:

• Die Zahl der Produkte wächst.
• Zusätzliche Erweiterungen erzeugen neue Endpunkte.
• Datenbanktabellen werden größer.
• Crawler entdecken bisher kaum verwendete Seiten.
• Hintergrundprozesse konkurrieren mit Besucheranfragen.
• Einzelne URLs werden durch externe Dienste ungewöhnlich häufig aufgerufen.

Eine plötzliche hohe Server-Auslastung ist deshalb selten allein mit einem Neustart behoben. Ein Neustart kann kurzfristig die Erreichbarkeit wiederherstellen, beseitigt aber weder einen teuren Endpunkt noch die auslösenden Zugriffe.

Notwendig ist eine zusammenhängende Betrachtung von:

• Monitoring-Daten,
• PSI-Werten,
• historischen Prozessdaten,
• PHP- und Datenbankaktivität,
• Webserver-Protokollen,
• Anwendungsstruktur,
• Zugriffsmustern.

Fazit: Entscheidend ist die Verbindung der einzelnen Spuren

In diesem Fall lieferte kein einzelnes Werkzeug die vollständige Antwort:

• Grafana und Telegram meldeten die ungewöhnliche Server-Auslastung.
• CPU- und PSI-Werte zeigten, dass nicht nur eine hohe Nutzung, sondern ein tatsächlicher Ressourcendruck bestand.
• Atop identifizierte PHP-FPM und MySQL als Hauptverursacher.
• Die Nginx-Logfiles führten zum ressourcenintensiven WooCommerce-Endpunkt.
• Die Analyse der IP-Adressen erklärte, warum das bestehende Standard-Rate-Limit nicht wirksam war.
• Ein kombiniertes Rate-Limit für Endpunkt und Crawler begrenzte die Zugriffe unabhängig von der jeweiligen IP-Adresse.

Genau darin besteht professionelle Linux-Server-Administration: nicht nur einen auffälligen Prozess zu beenden, sondern technische Messwerte, Protokolle und Anwendungsverhalten zu einer belastbaren Ursachenanalyse zusammenzuführen.

Ihr WordPress-/WooCommerce-Server ist plötzlich überlastet?

Wenn ein geschäftskritischer Linux-, WordPress- oder WooCommerce-Server nicht mehr zuverlässig reagiert, ist häufig rasche Unterstützung erforderlich – ohne dafür dauerhaft einen eigenen Administrator beschäftigen zu müssen.

Mit einem Linux Admin On Demand können KMU bei Bedarf auf erfahrene Unterstützung zurückgreifen, etwa für:

• die Analyse einer akuten Serverüberlastung,
• die Auswertung von Nginx-, Apache-, PHP- und MySQL-Protokollen,
• die Optimierung von WordPress-/WooCommerce-Servern,
• die Einrichtung von Grafana-Monitoring und Alarmierungen,
• die Absicherung teurer oder missbrauchter Endpunkte,
• die Konfiguration gezielter Nginx-Rate-Limits,
• die nachhaltige Beseitigung von Performance-Problemen.

Benötigen Sie Unterstützung bei einem überlasteten Linux-Server? Hier erfahren Sie mehr über uns!