Jeden Montagmorgen stürzt eine E-Commerce-Website ab. Das Team erstellt den VPS-Plan. Am folgenden Montag dasselbe Symptom: weiße Seiten, Nginx gibt 502 Bad Gateway zurück. Das eigentliche Problem war nicht die CPU – es war PHP-FPM, das gleichzeitig seine Arbeitskräfte und seinen Arbeitsspeicher erschöpft hatte. Festlegen des FPM-Gleichgewichts zwischen Antwortkapazität und Speicherobergrenze. Schlecht kalibriert wird der Server zum Glücksspiel: Entweder warten die Besucher, oder der Kernel beendet Prozesse.
PHP-FPM verwaltet einen Pool von PHP-Prozessen. Jede dynamische Anfrage verbraucht einen Worker. Wenn alle 20 Worker beschäftigt sind, wartet die 21. Anfrage in einer Warteschlange – die TTFB explodiert. Wenn Sie 200 auf 4 GB RAM ausführen, greift der OOM-Killer.
Lesen Sie den aktuellen Status, bevor Sie etwas berühren
Zunächst einmal pm.max_children = 50 aus einem Forum kopiert:
„Bash
FPM- und RAM-Prozesse (Beispielpool www)
ps --no-headers -o rss,cmd -C php-fpm8.2 | awk '{sum+=$1} END {print sum/1024 "Total MB"}'
Suchen Sie auch:
- **`listen.queue`** im `php-fpm-Status` – ausstehende Anfragen.
– **502/504** korrelierte mit Spitzen in Nginx-Protokollen.
- **`slowlog`** – Skripte, die Worker für lange Zeit festhalten.
| Signal | Interpretation |
| --- | --- |
| Schwanz > 0 regulär | Nicht genügend Worker oder Skripte zu langsam |
| Verwendeter RAM-Swap | Zu viele Worker oder PHP-Speicherverlust |
| Arbeiter im Leerlauf = max. dauerhaft | Untergroßer Pool |
| Arbeiter im Leerlauf = 0, RAM OK | Langsame Skripte, nicht zu kleiner Pool |
## Berechnen Sie pm.max_children ohne Zauberformel
Die Grundformel:
**max_children ≈ (dem PHP-Pool zugewiesener RAM) / (durchschnittlicher RAM pro Worker unter Last)**
Messen Sie den Arbeitsspeicher pro Mitarbeiter mit realistischem Datenverkehr (keine leere Homepage). Schweres WordPress benötigt oft zwischen 60 und 120 MB pro Prozess. Laravel oder Magento gehen höher.
Auf einem 8-GB-VPS, bei dem PHP 4 GB nutzen kann:
- Durchschnittlicher Arbeiter: 100 MB → theoretisch maximal 40.
- Behalten Sie **20–30 % Marge** für Betriebssystem, MySQL, Redis bei → streben Sie 28–32 an, nicht 40.
Die „pm“-Modi:
| Mode | Verhalten | Anwendungsfälle |
| --- | --- | --- |
| **dynamisch** | Spawn zwischen Minimum und Maximum je nach Last | Variable Standorte, guter Kompromiss |
| **statisch** | Immer max. aktive Arbeiter | Stabiles Laden, minimale Latenz |
| **auf Anfrage** | Bei Bedarf erstellt, Leerlaufzeitüberschreitung | Sehr eingeschränkter RAM, Kaltstart möglich |
:::Hinweis
**Denken Sie daran.** Das Erhöhen von max_children ohne Messung des RAM pro Worker verschiebt nur den Engpass: von der Warteschlange zum Swap und dann zum Absturz.
:::
## slowlog, request_terminate_timeout und häufige Fehler
**`request_slowlog_timeout`** (z. B. 5 s) + **`slowlog`** = Liste von Skripten, die Arbeiter monopolisieren. Korrigieren Sie den Code, bevor Sie Prozesse hinzufügen.
**`request_terminate_timeout`** unterbricht ein unendliches Skript – nützlich, kann aber bei schlechter Einstellung legitime Importe abschneiden.
Klassische Fehler:
1. **Kopieren Sie einen Produktionspool in einen gemeinsam genutzten Pool** – unterschiedliche Limits, Konto gesperrt.
2. **MySQL ignorieren** – 50 Worker × langsame Abfragen = 50 gesättigte DB-Verbindungen.
3. **OPcache deaktiviert oder falsch dimensioniert** – jeder Worker lädt den Bytecode neu, RAM überhöht (siehe [OPcache](/de/blog/opcache-php/)).
4. **hohe max_children + kein Seiten-Cache** – WordPress berechnet bei jedem Treffer alles neu.
## Die Spitze: Mehr Arbeiter verbergen eine langsame Anwendung
:::Höhepunkt
**PHP-FPM macht Ihren Code nicht schneller – es entscheidet, wie viele langsame Abfragen parallel ausgeführt werden können, bevor alles zusammenbricht.** Die Verdoppelung der Worker eines WordPress-Plugins auf 3 Sekunden Rendering verdoppelt größtenteils den Druck auf MySQL und die RAM-Rechnung. Die FPM-Einstellung optimiert die **Kapazität**; Profiling optimiert die **Dauer**.
:::
Das ist der Punkt, an dem die „unbegrenzten“ Angebote scheitern: Unbegrenzt auf der Besucherseite bedeutet nicht unbegrenzt auf der Seite des PHP-Prozesses.
## Entscheide dich und gehe ohne blinden Fleck voran
1. **Messen** Sie RAM/Worker und Tail-Länge unter tatsächlicher Last.
2. **Berechnen** max_children mit Marge; Wählen Sie dynamisch oder statisch.
3. **Aktivieren** Sie Slowlog und reparieren Sie die aufgelisteten Skripte.
4. Last und TTFB **erneut testen**; Vergleichen Sie Unterkünfte nur, wenn der Pool in Ordnung ist.
Für eine Upstream-Diagnose lesen Sie [Hohe TTFB](/de/blog/ttfb-diagnostic/). Um einen VPS mit vollem Poolzugriff zu filtern, durchsuchen Sie das [Verzeichnis](/de/verzeichnis/) oder den [Vergleich](/de/vergleich/).
## Häufig gestellte Fragen
### Wie berechnet man pm.max_children?
Für PHP verfügbarer RAM geteilt durch den durchschnittlichen Verbrauch eines Workers unter Last, mit einer Marge von 20–30 %.
### dynamisch, On-Demand oder statisch: Was soll ich wählen?
dynamisch für variablen Verkehr; statisch für stabile Belastung; OnDemand, wenn der Arbeitsspeicher sehr begrenzt ist und Sie mit der Startlatenz einverstanden sind.
### Was tun, wenn das Slowlog die Festplatte füllt?
Realistischer Schwellenwert, Skriptkorrektur, nicht nur Protokollrotation.
### Kann der Host meine FPM-Änderungen blockieren?
Ja, geteilt; Auf VPS kontrollieren Sie den Pool – prüfen Sie die vertraglichen Grenzen.
---
Bevor Sie die Worker erhöhen, fragen Sie: *Wie viele MB pro Anfrage und wie viele Sekunden pro Skript?* Wenn Sie es nicht wissen: FPM-Tuning ist eine Lotterie – keine Ausbeutung.