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.

<code>php_mt_srand(GENERATE_SEED());

*max_requests = fpm_globals.max_requests + php_mt_rand() &amp; 8191;</code>

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.