Worker Process Recycling (MaxConnectionsPerChild / max_requests)
Description
Configures application servers to periodically recycle worker processes after handling a fixed number of requests, bounding the cumulative impact of per-request memory leaks. When a worker reaches its request limit, it is gracefully terminated and replaced with a fresh process, releasing all leaked memory. Applicable to Apache HTTP Server (MaxConnectionsPerChild), PHP-FPM (pm.max_requests), Gunicorn (--max-requests with --max-requests-jitter for staggered recycling), Puma (worker_timeout), and Unicorn (after_fork with request counting). The recycling threshold should be set low enough to prevent OOM conditions but high enough to avoid excessive process churn — typical values range from 500 to 10000 requests per worker depending on application memory profile.
CVSS Vector Impacts
| Metric | Transition | Rationale |
|---|---|---|
| Availability (A) | H → L | Per-request memory leaks are bounded by the worker lifecycle; each worker is recycled after a fixed number of requests, releasing accumulated leaked memory before it can cause resource exhaustion. The application experiences brief per-worker restart latency rather than system-wide memory starvation. |
CWE Relationships
Verification
Check that application server worker recycling is configured with a finite request limit
# Expected: Non-empty output with a positive integer (not 0, which disables recycling)
# Expected: Non-empty output with a positive integer (not 0, which disables recycling)
# Expected: Non-empty output — --max-requests flag present on running Gunicorn workers