Balancing pm.max_children for variable concurrent request patterns

Answer

Set pm.max_children from measured worker memory, then cap it below the OS process limit. For bursty traffic, use pm = dynamic so idle capacity absorbs spikes without reserving every worker at all times.

Likely explanation

When concurrent requests exceed available children, PHP-FPM queues requests in the listen socket. A low pm.max_requests recycles workers frequently, which can appear as latency spikes under load. File-based sessions add serialization because PHP locks the session file for the duration of each request.

Confirmed facts

• pm.max_children is a hard ceiling on simultaneous workers per pool.
• pm = dynamic maintains spare workers between pm.min_spare_servers and pm.max_spare_servers, creating new workers only when demand rises.
• When all children are busy, listen.queue grows; sustained depth means requests are waiting.
• Default session.save_handler = files locks session files per request and cannot be unlocked by configuration alone.
• OS process limits (ulimit -u) can prevent PHP-FPM from reaching pm.max_children.

Configuration steps

1. Measure actual RSS under load. Run a representative load test, then inspect worker memory:

ps -o pid,rss,comm -C php-fpm

Use the median RSS as the average worker size.

1. Calculate a safe max_children. Subtract a system reserve from total RAM, divide by measured RSS, round down, then add 20-30% burst headroom. Confirm the result is below ulimit -u minus reserved system processes.
2. Apply pool settings. In the pool file, for example /etc/php/8.2/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = [calculated value]
pm.start_servers = [max_children / 2]
pm.min_spare_servers = [max_children / 4]
pm.max_spare_servers = [max_children * 3 / 4]
pm.max_requests = 2000

1. Enable status and slowlog. Add to the pool file:

pm.status_path = /status.json
request_slowlog_timeout = 1s

1. Monitor queue depth during load. Query the status endpoint:

curl -s http://localhost/status.json | jq '.listen.queue, .processes.active, .processes.idle'

A listen.queue consistently above zero during bursts means requests are waiting. Sustained depth above 5 suggests more workers or more server resources, provided memory and OS limits allow.

Session locking without changing handlers

File-based session locking cannot be disabled while keeping session.save_handler = files. Lowering session.gc_maxlifetime affects garbage collection frequency, not the per-request lock duration. To remove file-lock serialization, switch to Redis or Memcached.

Verification

• Confirm pm.max_children is below ulimit -u with headroom for other processes.
• Run free -m during load to ensure available memory stays positive.
• Watch listen.queue during a burst; near-zero queue depth with stable memory indicates appropriate sizing.

Key assumptions

This assumes PHP-FPM 7.4 or later on Linux with one pool. Worker memory varies by application, so theoretical estimates are unreliable. The 20-30% buffer is a starting point, not a guarantee.

Follow-up required

What is your measured peak concurrent request rate during the busiest hour? This determines whether the memory-based calculation needs adjustment or additional server capacity.