Nginx zeigt „Upstream-Zeitüberschreitung beim Lesen des Antwortheaders vom Upstream“ an. PHP-FPM gibt listen queue len 32 an. Sofortiger Reflex: Ändern Sie „pm.max_children“ von 50 auf 150. Der Datenverkehr wird absorbiert – RAM steigt auf 98 %, der OOM-Killer trifft MySQL. Ursache wurde nie behoben: ein synchroner Zahlungs-Webhook von 25 Sekunden pro Bestellung.
Gesättigtes PHP-FPM weist zwei Krankheiten mit ähnlichen Symptomen auf: wirklich nicht genügend Worker für eine kurze CPU-Auslastung oder Worker blockiert bei Netzwerk-E/A, langsame SQL-Abfrage, Dateisperre. Die Verwechslung der beiden kostet viel RAM – und verbirgt den wahren Engpass wochenlang.
Wenn das Slowlog überall die gleiche Anrufverfolgung anzeigt, handelt es sich nicht um ein FPM-Problem, sondern um diese Anrufverfolgung.
Die goldene Regel: 24-Stunden-Slowlog, dann PM-Einstellung – nie umgekehrt. Um max_children zu erziehen, ohne den kritischen Pfad zu verkürzen, müssen Kassierer eingestellt werden, während jeder Kunde noch mit ungedeckten Schecks bezahlt.
PHP-FPM-Status und Slowlog lesen
Aktivieren Sie zunächst die Sichtbarkeit:
pm.status_path = /fpm-status
ping.path = /fpm-ping
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
Schützen Sie „/fpm-status“ hinter Nginx – stellen Sie es nicht öffentlich zur Verfügung. Sättigungssignale:
- „aktive Prozesse“ ≈ max dauerhaft;
listen queue> 0;- Protokolle „Server erreicht pm.max_children“.
RAM-Formel: „(max_children × Speicher pro Kind) + Betriebssystem + MySQL < Gesamt-RAM“ – Marge mindestens 20 %.
Diagnose A vs. B: unzureichende Worker oder blockierender Code
A – unzureichende Worker: Anfragen weniger als 200 ms, hoher PHP-Prozessor, leeres Slowlog oder diversifizierte Traces → „pm.max_children“ in Zehnerschritten erhöhen, RAM überwachen.
B – Blockierungscode: aktive Worker, niedriger Prozessor, Slowlog konzentriert sich auf die gleiche Zeile (curl, PDO, file_get_contents) → in asynchrone Warteschlange stellen, Curl-Timeout drei bis fünf Sekunden, SQL-Index korrigieren – siehe fehlender MySQL-Index und PHP-Profilerstellung.
Richten Sie „fastcgi_read_timeout“ Nginx an der Anwendungsrealität aus – ein Nginx-Timeout, das kürzer als der Webhook ist, verbirgt das Problem in 504 ohne Slowlog. Bei Shared ist eine vom Host auferlegte Prozessobergrenze ein Signal für ein VPS-Upgrade und nicht für eine unendliche Optimierung.
Informationen zu N+1-Abfragen finden Sie unter MySQL Dynamic Site – eine Abfrageschleife kann alle Worker ohne hohe CPU blockieren.
PM-Optimierung: dynamisch, OnDemand, statisch
| Mode | Wann sollte man es verwenden | Risiko |
|---|---|---|
| dynamisch | Variabler Datenverkehr, kontrollierter RAM | Unerwartete Spitzen, wenn max_children zu niedrig ist |
| auf Anfrage | Sporadischer Datenverkehr, begrenzter RAM | Kaltstartlatenz |
| statisch | Flache Last, vorhersehbarer RAM | Verschwendung bei wenig Verkehr |
Beginnen Sie mit „pm =dynamic“ mit „pm.max_children“, berechnet nach der RAM-Formel. Testen Sie „On-Demand“ nur, wenn die Kaltstartlatenz für Ihr Publikum akzeptabel ist.
Der Gipfel: Keine Arbeiter mehr mit Sperrcode
Vergleichen Sie VPS, bei denen Sie PHP-FPM über das Verzeichnis steuern. Auf einer gemeinsamen Plattform ist die Prozessobergrenze nicht verhandelbar – die Diagnose bleibt dieselbe, aber die Lösung umfasst ein Upgrade oder eine Codeoptimierung.
Entscheide dich und gehe ohne blinden Fleck voran
Vor der Erhöhung von max_children:
- Status und Slowlog aktivieren – ohne Sichtbarkeit optimieren Sie blind.
- Klassifizieren Sie die Sättigung: hoher Prozessor (A) oder beschäftigte Arbeiter, niedriger Prozessor (B).
- Korrigieren Sie den Code oder SQL, wenn das Slowlog konzentriert ist – kein PM-Tuning vor der Korrektur.
- Passen Sie pm.max_children in Zehnerschritten mit dem dokumentierten RAM-Budget an.
- Ausrichten fastcgi_read_timeout Nginx- und Anwendungs-Timeouts (Curl, PDO).
- Auslastungstest desselben Endpunkts nach dem Patchen – die Warteschlange sollte bei normaler Auslastung auf Null bleiben.
Häufig gestellte Fragen
Woher weiß ich, ob PHP-FPM gesättigt ist?
Listen-Warteschlange größer als Null, max_children-Protokolle erreicht, 502/504 Nginx-Fehler, Latenz linear zum Datenverkehr. Aktivieren Sie pm.status_path, um vor dem Fehler zu beobachten – nicht erst danach.
Reicht die Erhöhung von max_children aus?
Vorübergehend für Diagnose A. Berechnen Sie den verfügbaren RAM; Wenn das Slowlog konzentriert ist, korrigieren Sie zuerst den Code – die Verdoppelung von Workern mit blockierendem Code führt zu einem OOM-Kill.
Wie erkennt man Blockierungscode?
slowlog PHP-FPM und Profiling-Tool. Symptom: Alle Worker sind beschäftigt, die CPU ist niedrig. Überall die gleiche Spur = identifizierter Engpass – kein Mangel an Arbeitskräften.
OnDemand vs. dynamisch?
dynamisch oder bedarfsgesteuert für variablen Datenverkehr; statisch für flache Belastung. OnDemand spart RAM, erhöht aber die Startlatenz – Test in der Vorproduktion.
Ein gesättigtes PHP-FPM deutet entweder auf einen Mangel an Kassen oder stationären Kassierern hin. Die Verwechslung der beiden kostet viel RAM.