PHP-FPM Pool Exhaustion in pfSense Web GUI Under Concurrent Sessions
0 reputation · 09 Aug 2025, 16:33 UTC
Problem Statement
The pfSense web GUI runs on lighttpd with PHP-FPM, using a default dynamic process pool with pm.max_children limited to 5 (CE) or 10 (Plus). Long-running administrative pages or API calls can saturate this pool, causing new connections to queue and eventually time out with a spinning loader in the browser.
Constraints and Uncertainty
Each PHP-FPM child consumes 30–80 MB RSS depending on loaded extensions, making aggressive increases to pm.max_children risky on low-RAM appliances. The GUI exposes only pm.max_children and request_terminate_timeout; advanced tuning options like static or ondemand modes require manual configuration. Additionally, pm.max_requests defaults to 0, meaning memory leaks in PHP extensions accumulate without automatic child recycling.
Specific Questions
1. What is the optimal pm.max_children value for a pfSense appliance with 4 GB RAM handling moderate concurrent admin sessions?
2. Should pm be switched to static or ondemand mode to balance memory usage against spawn latency under typical load patterns?
3. How can administrators monitor PHP-FPM pool saturation in real-time without enabling undocumented status endpoints?