PHP-FPM Ondemand vs. Dynamic: Speicher-Tuning für Hetzner Cloud VPS

Auf vielen Hetzner Cloud VPS Instanzen (z.B. CX22, CX32 oder CPX31) wird PHP-FPM mit den Standardwerten der Linux-Distribution betrieben (pm = dynamic, pm.max_children = 5). Das Resultat ist entweder:

1. Serverabsturz durch RAM-Erschöpfung: Wenn pm.max_children zu hoch gewählt wurde und gleichzeitige PHP-Prozesse den gesamten Arbeitsspeicher aufzehren.
2. Künstliche Engpässe: Wenn pm.max_children = 5 bei plötzlichen Besucheranstiegen greift und alle weiteren Anfragen in eine Warteschlange laufen (502 Bad Gateway / 504 Gateway Timeout).

Dieses Runbook liefert die exakte Formel zur Dimensionierung von PHP-FPM-Prozessmanagern auf modernen Cloud-Systemen.

1. Messung des tatsächlichen PHP-Speicherverbrauchs

Bevor wir Werte in Konfigurationsdateien eintragen, messen wir den realen durchschnittlichen Speicherverbrauch eines PHP-Worker-Prozesses Ihrer Anwendung:

# Durchschnittlichen RSS-Speicher (in MB) aller aktiven php-fpm8.3 Prozesse berechnen:
ps --no-headers -o "rss,cmd" -C php-fpm8.3 | awk '{ sum+=$1 } END { printf ("Durchschnitt: %.2f MB\n", sum/NR/1024) }'

Typische Werte in der Praxis:

• Schlankes Laravel / Symfony Projekt: 35 – 55 MB pro Worker
• WordPress mit WooCommerce: 65 – 95 MB pro Worker
• Shopware 6 / Magento: 110 – 160 MB pro Worker

2. Die mathematische Berechnungsformel

$$\text{pm.max_children} = \frac{\text{Für PHP reservierter RAM} - \text{Sicherheitsreserve}}{\text{Durchschnittlicher Speicherverbrauch pro Worker}}$$

Beispiel für eine Hetzner CPX31 (4 vCPU, 8 GB RAM):

• Physischer RAM: 8.192 MB
• Linux-Kernel, Nginx & Hintergrunddienste: 1.024 MB
• Lokale MySQL / MariaDB Datenbank: 3.072 MB
• Verfügbar für PHP-FPM: 4.096 MB
• Durchschnittlicher WooCommerce Worker: 80 MB

$$\text{pm.max_children} = \frac{4096 \text{ MB}}{80 \text{ MB}} \approx \mathbf{50}$$

3. Der Systemvergleich: pm = dynamic vs. pm = ondemand

Für produktive E-Commerce- und B2B-Websites mit hohem Traffic ist pm = dynamic die überlegene Wahl.

4. Die optimierte Pool-Konfiguration in /etc/php/8.3/fpm/pool.d/www.conf

# /etc/php/8.3/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

# Socket Backlog für Traffic-Peaks (muss mit sysctl somaxconn übereinstimmen)
listen.backlog = 65535

# Prozess-Manager Strategie
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 16

# Beendet Worker nach 1.000 Requests, um Memory Leaks von Drittanbieter-Plugins zu neutralisieren
pm.max_requests = 1000

# Timeout-Schutz gegen hängende Endlosschleifen
request_terminate_timeout = 60s

Starten Sie den PHP-FPM Dienst neu:

sudo php-fpm8.3 -t # Syntaxprüfung
sudo systemctl restart php8.3-fpm

5. Status-Monitoring über die PHP-FPM Statusseite

Aktivieren Sie in der Konfiguration pm.status_path = /status und überwachen Sie die Auslastung in Echtzeit:

# Aktuellen Zustand der Worker prüfen
curl http://localhost/status?full

Sie sehen auf einen Blick:

• active processes: Wie viele Anfragen werden aktuell berechnet.
• idle processes: Puffer für plötzliche Lastspitzen.
• listen queue: Muss stets 0 sein. Ein Wert > 0 signalisiert, dass Anfragen warten müssen und pm.max_children erhöht werden sollte.

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• Redis Persistenter Objekt-Cache für Enterprise-Systeme: Wiederkehrende Datenbankabfragen durch In-Memory-Speicher entlasten.
• Varnish Cache als Reverse Proxy vor Nginx: Extrem hohe Parallelzugriffe ohne Origin-Server-Last verarbeiten.
• Linux Kernel TCP BBR Aktivierung für Netcup & Hetzner: Paketverluste auf Mobilfunkverbindungen im DACH-Raum abfangen.