PHP-FPM Pool-Rechner
Berechne korrekte pm.max_children- und Spare-Server-Werte für deinen PHP-FPM-Pool aus RAM und Worker-Speicher — inklusive fertigem www.conf-Snippet.
MB — per ps prüfen (siehe unten)
Ergebnisse
- pm.max_children = —
- Maximale Anzahl gleichzeitig laufender Worker-Prozesse
- pm.start_servers = —
- Beim Start von FPM erzeugte Worker
- pm.min_spare_servers = —
- Minimale Anzahl bereitgehaltener Leerlauf-Worker
- pm.max_spare_servers = —
- Maximale Leerlauf-Worker, bevor FPM welche beendet
www.conf
Die meisten raten bei PHP-FPM-Pool-Größen oder kopieren Werte aus irgendeinem Blogpost. Das Ergebnis: entweder verschwendeter RAM oder ein Out-of-Memory-Crash unter Last. Dieser Rechner nimmt drei reale Zahlen und liefert ein korrektes www.conf-Snippet.
So funktioniert es
Die Pool-Größe wird begrenzt durch den verfügbaren RAM und den tatsächlichen Verbrauch pro Worker:
pm.max_children = floor((RAM × (1 − Puffer/100)) / Worker-Speicher)Der Sicherheitspuffer lässt Reserve für Betriebssystem, Webserver und Lastspitzen. Die Spare-Server-Werte skalieren mit max_children.
Den richtigen pm-Modus wählen
Der Rechner gibt pm = dynamic aus – der richtige Standard für die meisten Sites. Der Modus entscheidet, welche der folgenden Direktiven überhaupt greifen:
| Modus | Verhalten | Verwendete Direktiven | Geeignet für |
|---|---|---|---|
static | Feste Anzahl Worker, dauerhaft aktiv | nur max_children | Vorhersehbar hohe Last; maximaler Durchsatz, keine Spawn-Latenz |
dynamic | Pool wächst und schrumpft zwischen Spare-Grenzen | max_children, start_servers, min/max_spare_servers | Die meisten Sites – Balance aus RAM-Nutzung und Reaktionszeit |
ondemand | Keine Leerlauf-Worker; Spawn bei Request, Beendigung nach Timeout | max_children, process_idle_timeout | Wenig Last oder viele kleine Pools; spart RAM auf Kosten von Cold-Start-Latenz |
max_children zählt in jedem Modus – es ist der OOM-Schutz. Die Spare-Server-Werte wirken nur unter dynamic.
Was jeder Wert bedeutet
pm.max_children— die harte Obergrenze gleichzeitiger Worker-Prozesse. Diese Zahl verhindert OOM-Kills. Zu hoch gesetzt, frisst eine Lastspitze den gesamten RAM.pm.start_servers— wie viele Worker beim Start von FPM erzeugt werden. Ein Viertel des Maximums ist ein sinnvoller Warm-Pool.pm.min_spare_servers— die minimale Anzahl bereitgehaltener Leerlauf-Worker, um plötzliche Requests ohne Spawn-Latenz abzufangen.pm.max_spare_servers— die maximale Anzahl Leerlauf-Worker, die FPM toleriert, bevor er sie zur Speicherfreigabe beendet.
Den realen Worker-Speicher ermitteln
Raten Sie den Wert pro Worker nicht. Messen Sie ihn auf einem laufenden Server:
ps --no-headers -o rss -C php-fpm | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'Das mittelt den Resident Set Size aller php-fpm-Prozesse. Für einen typischen Shopware-6-Shop sind 60 MB pro Worker ein realistischer Startwert – schwerere Setups mit vielen Plugins erreichen 100 MB und mehr.