How Adjusting PHP‑FPM max_requests Stabilizes CPU and Memory Usage

Abstract

By optimizing the PHP‑FPM process restart mechanism, the fluctuations of CPU_IDLE and MEM_USED on production servers become smoother and more reliable.

Background

The delivery transaction service cluster showed severe CPU_IDLE swings on monitoring charts. Historically both CPU_IDLE and MEM_USED exhibit periodic drops and recoveries, prompting a deeper look at the PHP‑FPM manager.

Principle

Since PHP 5.3.3, PHP‑FPM is an official FastCGI manager supporting smooth start/stop, slow‑log, dynamic processes, and status reporting. It can operate in three modes: static, dynamic, and ondemand. The article uses the static mode, which creates a fixed number of FastCGI processes to avoid the overhead of frequent process creation.

The periodic CPU_IDLE and MEM_USED fluctuations were traced to the max_requests parameter. A too‑small value (1000) caused FastCGI processes to restart frequently during traffic peaks, increasing CPU load.

Optimization

Increasing max_requests to 10000 reduced the immediate CPU_IDLE spikes, as shown in the first improvement graph.

However, the periodic fluctuations persisted because the FastCGI restart mechanism still counted requests per process. When the count reached max_requests, the child process executed fcgi_finish_request, terminated, and the master process received a SIGCHLD signal, triggering fpm_children_bury to fork a new child.

In large‑scale production, hundreds of FastCGI processes can simultaneously hit the max_requests limit, causing the observed resource oscillations.

To keep the benefits of max_requests while smoothing resource usage, the article proposes a small modification to the PHP‑FPM source: assign different max_requests values to each child process by randomizing the limit.

php_mt_srand(GENERATE_SEED());

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

Result

After deploying the patched code, the final monitoring graphs show that both CPU_IDLE and MEM_USED have stopped their periodic swings, leading to stable CPU consumption and more accurate memory usage reporting.

This case demonstrates that fine‑grained tuning of PHP‑FPM in production environments can significantly improve backend performance stability.