Erfassen Sie den Zeitpunkt der Lastspitze und vergleichen Sie CPU, Arbeitsspeicher, PHP Workers, Datenbank und Access Log. Gruppieren Sie Anfragen nach URL, Status, IP-Adresse oder User Agent und profilieren Sie das aufwendigste Szenario. Begrenzen Sie die schädliche Quelle, korrigieren Sie die Abfrage oder Aufgabe, richten Sie einen Cache ein und entscheiden Sie erst danach über die Kapazität.
Hohe CPU- oder Speicherauslastung von WordPress ist keine Diagnose, sondern ein Signal, dass der Server mehr Arbeit verrichtet, als er bewältigen kann oder sollte. Ursache können legitimer Traffic, ein Bot, ein fehlgeschlagener Cron, eine langsame Abfrage, ein externer Timeout, die Bildgenerierung oder eine Endlosschleife sein. Ein sofortiges Server-Upgrade kann Zeit verschaffen, doch ohne Messung kehrt dasselbe Problem in größerem Maßstab zurück.
Die Untersuchung verknüpft den zeitlichen Verlauf der Infrastruktur mit dem Access-Log, den PHP-Prozessen, der Datenbank und Anwendungsereignissen. Sie müssen wissen, ob die Ursache viele günstige Anfragen oder einige extrem aufwendige sind. Nach der Stabilisierung folgen eine Reproduktion und eine Korrektur, anschließend eine angemessene Kapazitätsreserve. Das folgende Vorgehen ist dort read-only, wo zunächst Beweise gesammelt werden.
Bestimmen Sie Zeitpunkt, Quelle und Art der Erschöpfung
Sehen Sie sich die Diagramme für CPU, Arbeitsspeicher, Load Average, Festplatten-I/O, Swap, Datenbankverbindungen und PHP-Worker in derselben Zeitzone an. Eine kurze Spitze nach einem Deployment unterscheidet sich von einem schleichenden Speicherleck oder einem täglichen Cronjob. Halten Sie Beginn, Dauer und Rückkehr zum Normalzustand fest. Prüfen Sie auch etwaige Hosting-Limits und Throttling.
Unterscheiden Sie, ob PHP, die Datenbank, der Webserver oder eine externe Verbindung erschöpft ist. Eine volle Worker-Warteschlange kann daher rühren, dass jeder Worker auf eine API wartet, und nicht von zu wenigen Prozessen. Ein OOM-Ereignis kann einen Prozess beenden, ohne dass ein lesbarer WordPress-Fehler entsteht. Server- und Systemlogs gehören daher zu den Anwendungsdaten.
Gruppieren Sie die Anfragen aus dem Access-Log
Ermitteln Sie für das beobachtete Zeitfenster die häufigsten URLs, Methoden, Statuscodes, Quelladressen, User Agents und Antwortzeiten. Ein hohes Aufkommen bei Login, XML-RPC, Suche, REST-Endpunkten oder zufälligen 404-Fehlern kann auf Automatisierung hindeuten. Blockieren Sie keine legitime Suchmaschine nur anhand des User-Agent-Namens; prüfen Sie nach Möglichkeit Verhalten und Herkunft.
Eine langsame URL mit wenigen Aufrufen kann ebenso viele Ressourcen verbrauchen wie viele schnelle. Beobachten Sie Perzentile der Antwortzeit und die Antwortgröße, nicht nur die Anzahl. Unterscheiden Sie beim Cache zwischen Hit und Miss. Fügen Sie eine Korrelations-ID hinzu, wenn ein Request in eine Queue oder eine externe API weiterläuft. Schwärzen Sie Logs und bewahren Sie sie angemessen auf, da eine URL sensible Parameter enthalten kann.
- URL und Methode
- Anzahl, Zeit und Antwortstatus
- Cache-Hit oder -Miss
- Bot, Benutzer oder geplante Aufgabe
Profilieren Sie PHP, Datenbank und externe Aufrufe
Ermitteln Sie im Staging oder mit einem sicheren Produktionsprofiler Funktionen, Hooks und Plugins, die Zeit und Speicher verbrauchen. Achten Sie auf wiederholte Abfragen, große Collections ohne Paginierung und Schleifen über Metadaten. Das Slow Log der Datenbank zeigt die Abfrage samt Ausführungsplan. Optimieren Sie nicht nur die Datei ganz oben im Stack, wenn sie lediglich auf eine tiefere Abhängigkeit wartet.
Externe HTTP-Aufrufe haben ein Timeout und dürfen nicht jede Seitenanzeige blockieren. Cachen Sie das Ergebnis oder verlagern Sie die Synchronisierung in eine Warteschlange. Verarbeiten Sie Importe in Batches mit Checkpoint, nicht den gesamten Katalog in einer einzigen Anfrage. Erhöhen Sie das Speicherlimit nicht als einzige Maßnahme, solange Sie nicht wissen, ob ein Objekt legitim wächst oder in einer Endlosschleife Speicher verliert.
Stabilisieren Sie den Betrieb, ohne Beweise zu verlieren
Bei einem aktiven Vorfall kann ein Rate Limit für einen konkret missbrauchten Endpoint eingeführt, ein vorbereiteter Cache aktiviert, ein fehlerhafter Job pausiert oder eine aufwendige Funktion vorübergehend eingeschränkt werden. Jede Maßnahme braucht einen Verantwortlichen und eine Bedingung für die Rücknahme. Das vollständige Blockieren des gesamten Traffics oder Neustarts in einer Schleife können das Muster verschleiern und Bestellungen beschädigen.
Sichern Sie vor dem Beenden des Prozesses Logs, Metriken und den Zustand der Queue. Starten Sie bei einem Fehler in Cron oder dem Action Scheduler keine weiteren manuellen Versuche ohne Idempotenz. Wenn Sie die Anzahl der Worker erhöhen, beobachten Sie Datenbankverbindungen und Speicher; mehr Parallelität kann einen Zusammenbruch beschleunigen. Teilen Sie dem Betrieb mit, welche Funktion vorübergehend eingeschränkt ist.
- Gezieltes Rate Limiting
- Vorübergehende Deaktivierung eines fehlerhaften Hooks
- Erhaltene Metriken und Logs
- Zeitlich begrenzte Notfallmaßnahme
Beheben Sie die Ursache und schaffen Sie eine Kapazitätsreserve
Die Korrektur kann ein Index, eine Paginierung, das Entfernen eines doppelten Hooks, ein Objekt-Cache, ein kürzerer Timeout oder die Verlagerung der Arbeit in eine Warteschlange sein. Vergleichen Sie dasselbe Szenario vor und nach dem Eingriff und führen Sie einen Funktionstest durch. Lasttests sollten Sie in einer geeigneten Umgebung mit einem realistischen Mix an Anfragen und nach Absprache mit dem Anbieter durchführen, nicht unkontrolliert in der Produktion.
Legen Sie erst nach der Optimierung die Anzahl der Worker, den Arbeitsspeicher und die Skalierung entsprechend dem normalen Betrieb und der erwarteten Spitzenlast fest. Das Monitoring warnt vor einem Trend, bevor ein hartes Limit erreicht wird, und das Runbook verknüpft die Metrik mit den ersten Prüfschritten. Halten Sie nach einem Vorfall Auslöser, Auswirkung, Erkennungszeit und vorbeugende Maßnahme fest. Kapazität und effizienter Code ergänzen sich, sie ersetzen sich nicht.
Häufige Fragen
Hilft eine Erhöhung des PHP memory_limit?
Das kann eine legitim anspruchsvolle Aufgabe vorübergehend zum Abschluss bringen, löst aber keine Endlosschleife, keine große unbegrenzte Abfrage und kein Speicherleck. Messen Sie zuerst, was den Speicher belegt, und prüfen Sie die Erhöhung zusammen mit der Kapazität aller Worker.
Wie erkenne ich, ob ein Bot die CPU beansprucht?
Gruppieren Sie zur Spitzenzeit das Access-Log nach URL, IP, User-Agent, Anzahl und Antwortzeit. Prüfen Sie, ob die Anfragen den Cache umgehen und ein automatisiertes Muster aufweisen. Der User-Agent lässt sich fälschen, nutzen Sie daher mehrere Signale.
Ist leistungsstärkeres Hosting die Lösung?
Wenn die übliche legitime Last die Kapazität übersteigt, ja. Bei einem Codefehler oder Angriff verzögert es nur das Erreichen des Limits und erhöht die Kosten. Stabilisieren und profilieren Sie zuerst und kombinieren Sie dann Optimierung mit einer angemessenen Reserve.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
