PHP-FPM memory leak: per-worker RSS climbing until the box runs out

PHP-FPM workers are slowly bloating. RSS climbs hour by hour, the box runs out of RAM, the OOM killer shoots workers (or the master), and a restart makes everything look fine again. Hours or days later, the cycle repeats.

This is the slow-burn memory leak pattern, and it is almost always enabled by a single configuration value: pm.max_requests = 0. With worker recycling disabled, every byte a worker fails to release accumulates indefinitely. The leak itself may live in your application code, in a C extension, or in the PHP runtime. The diagnosis is not the same as the fix.

The signature is monotonic per-worker RSS growth with no plateau. Older workers carry more RSS than freshly forked ones. A restart resets the baseline and the curve starts over. Traffic-driven exhaustion looks different: workers come and go, RSS is roughly uniform across the pool, and the listen queue rather than RAM is the binding constraint.

What this means

PHP’s memory_limit constrains a single request’s heap. It does not bound what a worker accumulates across thousands of requests, and it does not see memory allocated by C extensions (ImageMagick, libxml, database client libraries, redis). A worker can report a flat memory_get_usage() while its RSS climbs to hundreds of megabytes. The only thing that reliably resets a worker’s footprint is process recycling, and the only built-in knob that controls that in FPM is pm.max_requests.

When pm.max_requests is 0 (the upstream default), workers live forever. Each request leaks a little, or accumulates a little into a static cache, or hands a reference to a long-lived structure. The growth is monotonic because nothing reclaims it. Eventually total worker footprint approaches system or cgroup RAM. Performance stays acceptable until swapping starts, then latency spikes non-linearly, then the OOM killer fires. The transition from “fine” to “catastrophic” happens in the last few percent of RAM.

flowchart TD
  A["pm.max_requests = 0
workers never recycle"] --> B["Each request leaks
or accumulates a little"]
  B --> C["Per-worker RSS climbs
monotonically, no plateau"]
  C --> D["Older workers > newer workers"]
  D --> E["Total FPM RAM approaches limit"]
  E --> F["Swap, then OOM killer"]
  F --> G["Workers or master killed"]
  G --> H["Restart resets RSS"]
  H --> B

Restarting PHP-FPM is not a fix. It is a reset that buys time until the next OOM.

Common causes

Quick checks

These are read-only. None of them change state.

# Average and max worker RSS in KB (master excluded)
ps -eo pid,rss,cmd | grep '[p]hp-fpm' | grep -v master | \
  awk '{sum+=$2; n++; if($2>max) max=$2} END {printf "workers=%d avg=%.0fMB max=%.0fMB\n", n, sum/n/1024, max/1024}'

# Accurate per-worker memory using PSS (accounts for shared opcache pages)
smem -P php-fpm -c 'pid pss rss' -s pss

# Effective pm.max_requests and process manager mode
php-fpm -tt 2>&1 | grep -E "pm =|pm.max_requests"

# PHP version (compare against known leak fixes)
php-fpm -v

# Per-worker request count and age (correlate RSS against requests served)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E "pid|requests served|start since|state"

# Recent OOM kills targeting php-fpm
dmesg -T | grep -i "out of memory\|oom.*php\|killed process" | tail -20

# Worker exits by signal (signal 9 = OOM kill, 11 = segfault, 7 = SIGBUS)
grep -c "exited on signal" /var/log/php-fpm/error.log

The two signals that confirm the pattern: RSS scales with requests served (older workers with more requests carry more RSS), and pm.max_requests is 0 or unset. If RSS is uniformly high regardless of request count, you have a large baseline footprint, not necessarily a leak.

How to diagnose it

1. Confirm the leak is per-worker, not aggregate. Poll per-worker RSS a few times over an hour. A leak shows monotonic growth in individual PIDs. Aggregate growth with stable per-worker RSS means you are spawning more workers (a capacity issue), not leaking.

2. Check the enabling condition. Run php-fpm -tt 2>&1 | grep pm.max_requests. If it is 0, that is the lever. If it is already set and you still leak, either the value is too high for the leak rate, or you have a fast leak in an extension.

3. Join RSS to requests served. For each worker PID, compare RSS (from ps) against requests served (from fpm-status?full). A clean linear relationship between requests served and RSS is a per-request leak. A step function tied to a specific endpoint is a code-path-specific leak.

4. Distinguish PHP-heap from C-level leaks. If memory_get_usage(true) stays flat while RSS climbs, the leak is in a C extension or the runtime allocator, invisible to PHP’s memory accounting. This is common with image processing, XML parsing, and persistent database connections. PHP-level leaks show up in memory_get_usage().

5. Rule out a known runtime bug. Several PHP patch versions shipped memory leaks that were fixed in later minors. If every worker leaks uniformly regardless of traffic mix, check your PHP version against the known fixes below before chasing application code.

6. Profile when narrowing down. Once containment is in place, use last request memory from fpm-status?full per endpoint, and application-level profiling, to identify which request type drives the growth.

Known PHP runtime leaks

Several PHP runtime memory leaks present exactly like this pattern: uniform RSS growth across all workers, independent of application code. Patching is the only real fix. pm.max_requests is containment.

• PHP 8.1 before 8.1.18: opcache-less FPM leak via zend_map_ptr not being reset between requests, causing unbounded growth of interned class name strings. Tracked as GH-8646.
• PHP 8.2 before 8.2.23: opcache shared memory placement leak (GH-13775). The opcache SHM mapping was allocated too close to the heap. Notably, this leak did not reproduce under Valgrind or massif, which made it hard to diagnose from profiles. Fixed in 8.2.23.
• PHP 8.3 before 8.3.7: memory leak on stream filter failure (GH-13264).
• PHP 8.3 before 8.3.20: memory leak when destroying PDORow.

If you are on an older patch release, upgrade before spending days in application profiling. A one-line pm.max_requests = 500 buys you the time to do the upgrade safely.

A per-child RSS-based recycling directive (pm.max_memory) has been proposed (GH-17661) but is not merged as of mid-2026. Until it exists, pm.max_requests is the only built-in recycling knob.

Metrics and signals to monitor

Fixes

Immediate containment: enable worker recycling

Set pm.max_requests to a finite value in the pool config. A useful starting band is 500 to 1000 for most applications. A worker that has served its limit finishes the current request, delivers the response, then exits and the master forks a replacement. There is no mid-request interruption.

; /etc/php/8.x/fpm/pool.d/www.conf
pm.max_requests = 500

Reload the service to apply. Under systemd, systemctl reload php8.x-fpm sends SIGUSR2 to the master, which gracefully reloads pool configuration. Workers in flight finish their current request.

The tradeoff: lower values recycle more often, costing fork overhead and per-process warmup (cold application-level caches, fresh connection pools) for the replacement worker’s first requests. Higher values let a slow leak fill more RAM before recycling. If RSS climbs back to dangerous levels within the request budget, lower the value.

Do not set it absurdly low (for example 50). The fork and warmup cost per request starts to dominate. Do not set it absurdly high (for example 10000) if you have a real leak; you are just lengthening the fuse.

Verify recycling is actually happening

After applying, confirm workers are cycling. Poll fpm-status?full and watch requests served per worker. Values should cluster below pm.max_requests and reset as workers are replaced. If you see workers with requests served far exceeding the limit, recycling is broken or the reload did not take.

Also watch worker exit logs. Periodic clean exits at a rate consistent with your traffic and pm.max_requests are healthy. A sudden absence of exits after a config change means the new value did not load.

Narrow down the leak source

Containment is not a fix. Once the box is stable, find the leak.

• If RSS scales with requests served uniformly, suspect a per-request leak. Compare last request memory per endpoint from fpm-status?full. Endpoints with disproportionate last request memory are your first suspects.
• If memory_get_usage(true) is flat but RSS climbs, the leak is C-level. Common culprits: persistent PDO connections, MySQL client buffers, libcurl handles, Imagick objects, the redis extension. These are invisible to PHP’s memory accounting and unaffected by memory_limit.
• If growth is concentrated in a subset of workers, the leak is triggered by specific code paths. Cross-reference high-RSS workers’ recent script field from full status against application endpoints.
• If growth is uniform across all workers regardless of traffic mix, suspect a runtime bug. Check PHP version against the known fixes before chasing application code.
• Avoid gc_collect_cycles() in a hot loop. The cycle collector is O(n) in cycle roots. Calling it every request on a busy worker can cost more CPU than it saves. Call it every N requests if needed, not unconditionally.

Consider ondemand as a containment layer

pm = ondemand kills idle workers after pm.process_idle_timeout (default 10s). This caps how long any single worker can accumulate memory, because idle workers do not persist. It does not fix the leak. It limits the number of long-lived workers. Useful on hosts with bursty traffic where workers frequently go idle. Less useful on constantly busy pools where workers never idle out.

Prevention

• Set pm.max_requests on every production pool. Treat 0 as a misconfiguration, not a default. 500 to 1000 is near-zero cost (a fork every few hundred requests) and removes the entire class of slow OOM incidents.
• Monitor per-worker RSS as a trend, not a snapshot. The leak is only visible over hours. Poll frequently enough to see the slope.
• Normalize RSS by requests served. The leak rate is RSS growth per request, not RSS alone. A worker that grew 50MB over 500 requests is leaking roughly 100KB per request.
• Use PSS, not RSS, for capacity math. Naive workers * RSS overestimates footprint by 30 to 50% because forked workers share read-only pages including the opcache segment. smem or /proc/<pid>/smaps_rollup Pss gives accurate per-worker memory.
• Keep PHP patched. Runtime leaks get fixed in patch releases. Staying current removes whole classes of leak without any application work.
• Set request_terminate_timeout as well. A stuck worker holding a slot forever is a different failure, but it compounds a memory leak by reducing the effective worker count. 30 to 60 seconds is a reasonable starting point.
• Size pm.max_children by memory, not CPU. Formula: max_children = (total_RAM * 0.7 - OS_overhead) / avg_worker_RSS. Blindly raising max_children on a leaking pool accelerates the OOM.

How Netdata helps

• Per-second per-worker RSS trends make the slow-burn slope visible long before the box swaps. Snapshots miss it; a per-second series catches the monotonic growth pattern that defines this incident class.
• Correlating RSS against requests served per worker turns a raw memory chart into a leak-rate signal. A flat RSS-per-request line means no leak; a rising line means per-request accumulation. This is the fastest way to confirm the pattern without manual polling.
• Cgroup and host memory metrics alongside FPM metrics let you see total footprint approach the limit, swap onset, and OOM kills in one view, rather than stitching dmesg, free, and ps after the fact.
• Worker exit signal tracking distinguishes normal pm.max_requests recycling (clean exit, periodic) from OOM kills (signal 9) and segfaults (signal 11), so you know whether the box is healing itself or bleeding.
• Anomaly detection on RSS and request duration surfaces the leak before it crosses a hard threshold. This matters because the transition from fine to catastrophic happens in the last few percent of RAM, and threshold-based alerts fire too late to prevent the OOM.

Related guides

• PHP-FPM 504 Gateway Timeout: requests accepted but never finishing in time
• PHP-FPM active processes near max_children: reading pool utilization
• How PHP-FPM actually works in production: a mental model for operators
• PHP-FPM idle processes at zero: no burst headroom left
• PHP-FPM listen queue growing: the earliest signal of saturation
• PHP-FPM “server reached pm.max_children setting (N), consider raising it”
• PHP-FPM monitoring checklist: the signals every production pool needs
• PHP-FPM monitoring maturity model: from survival to expert
• PHP-FPM request duration climbing: spotting stuck and outlier workers
• PHP-FPM sizing pm.max_children: by memory, not by CPU cores
• PHP-FPM slow log: turning on request_slowlog_timeout to see what is slow
• PHP-FPM slow request cascade: one slow dependency drains the whole pool