pm.max_requests is a process manager setting that limits how many requests a worker process handles before it is recycled. It is used in PHP-FPM to reduce memory leaks, stale state and long-lived process drift, while allowing workers to be replaced cleanly without restarting the whole service.
What pm.max_requests actually controls
pm.max_requests is a lifecycle control, not a performance tweak. It tells PHP-FPM to retire a worker after it has processed a set number of requests so the pool can recover from gradual memory growth, state drift, or extension behaviour that accumulates over time.
That recycling model matters because long-running application workers often behave differently from short-lived request handlers. When workers are reused for many requests, small leaks, cached state, or residue from earlier requests can compound until they affect stability, latency, or correctness.
Why request-based worker recycling matters
The setting exists to balance efficiency against process hygiene. Reusing workers avoids the cost of constant process creation, but eventually every reused worker becomes a liability if it is allowed to live too long with accumulated memory pressure or stale in-process data.
By forcing renewal after a bounded request count, pm.max_requests gives operators a predictable reset point. That reset can reduce hard-to-diagnose faults that only appear after sustained traffic, especially in environments where the application or its extensions are not perfectly memory-clean.
How pm.max_requests fits into PHP-FPM tuning
This directive is usually tuned alongside other PHP-FPM process manager settings such as pool size, start behaviour, and idle worker limits. It is one part of a broader control strategy for how many requests a process should handle, how long it should stay alive, and how aggressively the pool should be refreshed.
The practical trade-off is simple: lower values refresh workers more often, which can improve cleanliness but increase churn; higher values reduce churn, but extend the time a worker can carry memory residue or stale runtime state. The right setting depends on the application, extensions, traffic pattern, and observed resource drift.
In operational terms, the value should be treated as an evidence-based tuning parameter. If worker memory grows steadily, if some requests behave differently after long uptime, or if restarts temporarily “fix” odd behaviour, pm.max_requests is often one of the first knobs to review.
What this setting does not solve
pm.max_requests is a mitigation, not a root-cause fix. It can mask symptoms of leaks or unstable code paths, but it does not remove the underlying defect in the application, extension, or request lifecycle.
It also does not protect a service from unsafe code, input handling issues, or insecure application logic. It only limits how long a worker remains in circulation before it is replaced, which can reduce the blast radius of drift but cannot guarantee correctness or security on its own.
Because worker recycling affects statefulness, the setting should be understood as part of the service’s resilience model. It helps keep long-lived PHP processes healthy, but it should be paired with code fixes, memory monitoring, and broader runtime hardening where needed.
Risk and Threat Considerations
When pm.max_requests is set too high, unstable workers can linger long enough for memory growth, stale state, or error-prone extension behaviour to become operationally visible. In a busy PHP-FPM pool, that can lead to degraded availability, inconsistent responses, or hard-to-reproduce faults that only appear after prolonged reuse.
Failure mechanism: A worker accumulates memory or state drift across repeated requests, then continues serving traffic long after the process has become unhealthy.
Impact: The pool can become less stable, application behaviour can diverge between workers, and operators may see intermittent failures that are difficult to trace back to the reused process state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Process recycling supports controlled service account and runtime lifecycle hygiene. |
| Recommendation — Review worker lifecycle settings to reduce long-lived process drift and limit stale runtime state. | ||
| NIST CSF 2.0 | PR.PS-04 — Platform Vulnerabilities Are Managed | Tuning process recycling helps manage runtime weaknesses from leaks and stale worker state. |
| Recommendation — Adjust process lifecycle controls to reduce exposure from unstable or drifting runtime processes. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration Management | pm.max_requests is a configuration setting that affects service stability and resilience. |
| Recommendation — Document and review PHP-FPM lifecycle settings as part of configuration control. | ||
Practitioner Guidance
What to watch for: Tune pm.max_requests against real process behaviour, not folklore. If workers grow in memory over time, recycle more aggressively; if churn is excessive and workers remain healthy, the value may be unnecessarily low.
Governance implication: Treat this as an operational control with ownership, because the right value depends on workload characteristics, extension quality, and the cost of process replacement. The setting should be reviewed when traffic patterns or deployed code change.