PHP-FPM
Also Known As
PHP-FPM
FastCGI Process Manager
PHP process manager
TL;DR
PHP FastCGI Process Manager — a high-performance PHP process manager that manages worker pools for web servers like Nginx.
Explanation
PHP-FPM (FastCGI Process Manager) runs PHP as a separate service communicating with the web server (typically Nginx) via FastCGI. It manages a pool of PHP worker processes, restarting crashed workers, and supports dynamic/static/ondemand process management strategies. Key configuration includes pm.max_children (limits concurrency and memory), request_terminate_timeout (prevents runaway processes), and slowlog (identifies slow scripts). Unlike Apache mod_php, PHP-FPM isolates PHP execution from the web server, improving security and allowing different pools per virtual host.
Diagram
flowchart TD
REQ[HTTP Request] --> NGINX[nginx]
NGINX -->|FastCGI| MASTER[PHP-FPM Master]
MASTER --> W1[Worker 1<br/>handling request]
MASTER --> W2[Worker 2<br/>idle]
MASTER --> W3[Worker 3<br/>idle]
W1 --> OPCACHE[OPcache<br/>compiled bytecode]
W1 --> DB[(Database)]
W1 --> REDIS[(Redis)]
INFO[Each worker handles one request<br/>pm.max_children = concurrency limit]
style MASTER fill:#6e40c9,color:#fff
style W1 fill:#238636,color:#fff
style OPCACHE fill:#1f6feb,color:#fff
style INFO fill:#d29922,color:#fff
Common Misconception
✗ PHP-FPM pool configuration is a set-and-forget server setting. Pool configuration — pm.max_children, pm.start_servers, and pm.max_requests — directly affects memory usage, concurrency, and the frequency of memory leak mitigation. It should be tuned to the specific application and server resources.
Why It Matters
PHP-FPM manages a pool of PHP worker processes — correct pool sizing and timeout configuration directly determines throughput, memory usage, and behaviour under load.
Common Mistakes
- Using the default pm = dynamic settings without tuning for your application's memory per worker.
- Setting pm.max_children too high — workers exceed available RAM and the server starts swapping.
- Not setting request_terminate_timeout — runaway scripts hold workers indefinitely, starving new requests.
- Not monitoring the PHP-FPM slow log — slow requests are invisible without it.
Code Examples
✗ Vulnerable
# php-fpm pool.conf — untuned defaults:
pm = dynamic
pm.max_children = 50 ; Too high if each worker uses 100MB — that's 5GB RAM
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
; request_terminate_timeout = 0 — infinite by default, runaway scripts block workers
✓ Fixed
; /etc/php/8.3/fpm/pool.d/www.conf
[www]
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50 ; workers x memory < available RAM
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 10
pm.max_requests = 500 ; recycle to prevent memory leaks
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
pm.status_path = /fpm-status
chdir = /var/www/app
php_admin_value[open_basedir] = /var/www/app:/tmp
php_admin_value[disable_functions] = exec,system,shell_exec
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
36
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 1
No pings yesterday
Perplexity 11
Amazonbot 9
Unknown AI 3
Ahrefs 3
SEMrush 2
Majestic 1
Google 1
ChatGPT 1
Also referenced
How they use it
crawler 30
pre-tracking 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Set pm=dynamic, pm.max_children = (RAM - 512MB) / avg_worker_MB, pm.max_requests=500 to prevent memory leaks accumulating indefinitely
📦 Applies To
PHP 5.3+
web
🔗 Prerequisites
🔍 Detection Hints
pm.max_children too low causing 502s under load; pm=ondemand with cold-start latency; no pm.max_requests causing memory growth
Auto-detectable:
✓ Yes
php-fpm-status
datadog
prometheus
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: Low
✗ Manual fix
Fix: Medium
Context: File