PHP-FPM-Pool-Tuning in Produktion — die static-vs-dynamic-vs-ondemand-Entscheidung

Das mit Abstand häufigste PHP-Performance-Problem bei eingehenden Audits: PHP-FPM im dynamic-Modus mit Standard-Dimensionierung, die 2014 für einen 1-GB-VPS passend war, läuft auf einer 16-GB-Maschine, während die Anwendung bei 5 Children verhungert. Das andere häufige: pm = ondemand auf einer High-RPS-Produktions-Site, die bei jedem Burst die Fork-Kosten bezahlt.

Dies ist das Pool-Tuning, das wir beim Onboarding anwenden, die Slowlog-Disziplin, die wir danach durchsetzen, und wie man weiß, ob es funktioniert.

Der Pool, den wir üblicherweise ausliefern

; /etc/php/8.3/fpm/pool.d/www.conf
pm = static
pm.max_children = 50
pm.max_requests = 1000
 
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
 
pm.status_path = /fpm-status
ping.path = /fpm-ping

static, sobald Sie das richtige max_children kennen — keine Fork-Kosten bei Bursts, vorhersehbarer Speicher. Berechnen Sie max_children als (verfügbarer RAM - OS-Overhead - andere Services) / Speicher pro Prozess. Messen Sie den Speicher pro Prozess unter Last, nicht im Leerlauf.

Der vollständige Beitrag behandelt:

• Die pm-Modi — static vs dynamic vs ondemand, und wann jeder richtig ist
• pm.max_children aus dem unter Last beobachteten Speicher pro Prozess berechnen
• pm.max_requests und warum es auf 0 (Default) zu setzen falsch ist
• Slowlog-Tuning — die 5-Sekunden-Schwelle und die Muster, die sie zutage fördert
• Die /fpm-status-Nginx-Verdrahtung und was jede Metrik bedeutet
• PHP-FPM-Tuning mit der OPcache + JIT-Konfig auf demselben Host koordinieren

Wir liefern diese Konfiguration auf jedem gemanagten PHP-Stack aus.