PHP-FPM Pool Exhaustion in pfSense Web GUI Under Concurrent Sessions

Answer

The optimal pm.max_children for a pfSense appliance with 4 GB RAM handling moderate concurrent admin sessions is typically 6–10, derived by dividing the RAM available to PHP by the average RSS per child and subtracting a safety margin.

Likely Explanation

Long‑running administrative pages or API calls keep PHP‑FPM children busy, causing the pool to exhaust and new connections to queue, resulting in browser spinner timeouts.

Confirmed Facts

1. Each PHP‑FPM child consumes 30–80 MB RSS depending on loaded extensions.
2. Default pm.max_children is 5 (CE) or 10 (Plus); the GUI only exposes this value and request_terminate_timeout.
3. Changing pm mode to static permanently reserves memory for peak load, which is wasteful for bursty admin traffic; ondemand adds spawn latency after idle periods, so dynamic mode remains the recommended default.
4. Manual edits to the generated PHP‑FPM pool configuration may be overwritten by firmware or package updates.

Steps to Determine Safe pm.max_children

1. Measure actual RSS per child under representative load: ps -o rss= -o command= | grep php-fpm.
2. Calculate available RAM for PHP (total RAM minus OS and state‑table usage) and divide by the measured RSS; round down and subtract 1–2 as a safety margin.
3. Set pm.max_children to the resulting value (e.g., 6–10 for 4 GB RAM with ~40 MB average RSS).
4. Keep pm in dynamic mode; avoid static or ondemand unless specific latency or memory‑reservation needs are proven.
5. Monitor pool saturation using standard FreeBSD tools: ps aux | grep php-fpm to count active children, sockstat -4 | grep fpm for socket connections, and lighttpd error logs (Status > System Logs) for FastCGI timeout messages.

Missing Diagnostic Detail

What is the observed average RSS per PHP‑FPM child on your specific appliance? This measurement determines whether 6, 8, or 10 children can be safely configured.