Optimizing PHP-FPM Process Restart Mechanism to Stabilize CPU Idle and Memory Usage

Abstract : By optimizing the PHP‑FPM process restart mechanism, the fluctuations of CPU_IDLE and MEM_USED on production servers were reduced, resulting in smoother and more reliable resource utilization.

Background : The delivery transaction service cluster exhibited severe CPU_IDLE volatility, as shown in monitoring graphs. Periodic sharp drops and recoveries in MEM_USED were also common.

Principle : Since PHP 5.3.3, PHP‑FPM is an official FastCGI manager supporting graceful start/stop, slow‑log, dynamic processes, and status monitoring. It offers three process management modes—static, dynamic, and ondemand. The static mode, which creates a fixed number of FastCGI workers, was used in production.

Problem Analysis : The root cause of the periodic CPU and memory swings was traced to the max_requests parameter. This setting forces each FastCGI worker to restart after handling a certain number of requests, mitigating third‑party extension memory leaks. In the online configuration the value was set to a low 1000, causing frequent restarts during traffic peaks and increasing CPU load. Raising max_requests to 10000 improved CPU_IDLE, but the oscillation persisted.

Optimization : Although increasing max_requests reduces restart frequency, the mechanism still triggers when the counter reaches the limit, and many workers restart simultaneously, creating the observed spikes. To keep the safety benefits while avoiding collective restarts, the source code of PHP‑FPM was patched so that each worker receives a slightly different max_requests value.

Code Changes :

php_mt_srand(GENERATE_SEED());

*max_requests = fpm_globals.max_requests + php_mt_rand() & 8191;

Result : After deploying the patched binary, monitoring graphs showed that both CPU_IDLE and MEM_USED fluctuations were eliminated, providing stable CPU usage and more accurate memory consumption data.

Conclusion : Fine‑grained tuning of PHP‑FPM, especially randomizing max_requests per worker, effectively stabilizes resource metrics in high‑load production environments. This case demonstrates the importance of deep understanding and targeted modification of backend components for operational reliability.