PHP-FPM memory_limit vs worker RSS: why workers exceed the limit you set

You set memory_limit = 256M in php.ini. You check ps and see PHP-FPM workers sitting at 350 MB, 400 MB, sometimes more. No PHP error fired. No “Allowed memory size exhausted” in the logs. The workers did not crash. They are just bigger than the limit you set.

This is not a bug, and usually not a leak. It is the expected result of how PHP’s memory manager is scoped, which most operators learn only after being paged at 3 a.m. for an OOM kill they cannot explain.

memory_limit constrains one thing: the Zend Memory Manager (ZendMM) heap, allocated via emalloc() during a single request. Worker RSS includes that heap plus everything else the process maps: extension allocations through libc malloc, OPcache shared memory, shared library pages, the interpreter binary, and cumulative allocations from previous requests that were never returned to the OS. None of those are counted by memory_limit.

What memory_limit actually is

PHP’s memory_limit is enforced by ZendMM, the allocator behind every emalloc(), efree(), estrdup(), and related call in the PHP runtime. When a script creates a string, array, or object, ZendMM hands out memory from its heap and tracks every byte. When the running total crosses memory_limit, PHP raises a fatal error: “Allowed memory size of X bytes exhausted.”

Two properties define the scope:

• Per-request, not per-process. ZendMM resets its accounting at request startup. A worker that handled a 200 MB request then a 5 MB request is not accumulating toward a 205 MB limit. The counter starts fresh each request.
• ZendMM only. Allocations through libc malloc(), calloc, or realloc bypass ZendMM entirely. PHP extensions written in C routinely allocate through libc, not through emalloc(). Those allocations are invisible to memory_limit.

Every byte allocated through ZendMM is counted. Bytes allocated through any other path are not.

You can observe this from PHP itself. memory_get_usage(false) returns the sum of all emalloc() calls (ZendMM-tracked usage). memory_get_usage(true) returns the total size of all memory segments ZendMM has requested from the OS. Neither includes extension allocations made through libc.

How workers grow past it

Worker RSS as reported by ps, top, or /proc/[pid]/status (VmRSS) is a kernel-level measurement. It sums every resident physical page mapped into the process, regardless of which allocator requested it. RSS includes:

• The ZendMM heap (the only thing memory_limit bounds)
• Extension allocations via libc malloc (ImageMagick, libxml, PDO drivers, libcurl, GD, others)
• OPcache shared memory, mapped via mmap(MAP_SHARED), counted in every worker’s VmRSS through the RssShmem component even though the physical pages exist only once
• Shared library pages (libc, libpcre, libxml, libcurl) mapped into every forked worker
• The PHP interpreter binary, whose read-only pages are shared across all workers via copy-on-write
• Cumulative allocations from previous requests that libc never returned to the OS

flowchart TD
    ML[memory_limit 256M] -->|bounds only| ZH[ZendMM heap - emalloc - per request]
    ZH --> RSS[Worker RSS 400M]
    EXT[Extension malloc - libc - persists] --> RSS
    OPC[OPcache shared segment] --> RSS
    SHL[Shared library pages] --> RSS
    BIN[Interpreter binary pages] --> RSS
    CUM[Cumulative allocs across requests] --> RSS

memory_limit is a ceiling on one contributor to RSS. The other contributors are unbounded by PHP’s accounting. A worker with memory_limit = 256M can legitimately sit at 400 MB RSS if extensions allocated 100 MB through libc and shared pages account for another 50 MB, with no PHP error fired.

Shared memory double-counting

PHP-FPM workers are forked from the master process and share a large set of read-only pages: the interpreter binary, shared libraries, and the OPcache segment. The kernel maps these pages into every worker’s address space, so VmRSS counts them in every worker individually.

If you sum RSS across all workers, you overstate actual physical usage by 30 to 50 percent. A host with 50 workers each reporting 80 MB RSS might show 2.5 GB on paper but only consume 1.5 GB of physical memory. The OPcache segment alone, typically 64 to 256 MB, is counted in full in every worker’s VmRSS.

Use PSS (Proportional Set Size) for accurate accounting. PSS divides shared page costs proportionally among the processes that map them. The smem utility reports PSS directly:

# Accurate per-process memory - accounts for shared opcache and libs
smem -P php-fpm -c 'pid pss rss' -s pss

USS (Unique Set Size), also from smem, reports only memory private to each process. For capacity planning, PSS is the right number. For leak detection, USS strips out shared noise and shows what each worker is actually accumulating on its own.

C-level extension leaks

The hardest case to diagnose is an extension that leaks through libc. A worker whose memory_get_usage() returns a flat 20 MB but whose RSS climbs to 200 MB over hours has a C-level leak. PDO persistent connections, libcurl handles that are never closed, and Imagick objects that hold native resources all allocate outside ZendMM. PHP’s memory_limit will never catch this. The worker will grow until the OS OOM killer intervenes or pm.max_requests recycles it.

Where this shows up in production

“memory_limit is 256M but workers are at 400M.” Baseline case. The gap is extension allocations, shared pages, and cumulative request residue. It is normal. The operator’s mistake is expecting memory_limit to be a process memory cap. It is not and has never been.

Summed RSS exceeds physical RAM. An operator sums ps RSS across all workers, gets a number larger than total RAM, and concludes the system should have OOM’d already. It did not because the sum double-counts shared pages. Use PSS instead.

Workers grow monotonically with pm.max_requests = 0. Without recycling, cumulative allocations from both ZendMM (if the application leaks) and libc (if extensions leak) accumulate without bound. RSS climbs over hours or days until the OOM killer fires. Setting pm.max_requests to 500 or 1000 forces periodic recycling, which resets the worker’s memory footprint.

Container OOM kills with no PHP error. In containerized deployments, the cgroup memory limit is the binding constraint. FPM workers do not know about cgroup limits. They allocate until the cgroup OOM killer strikes, killing workers or the master with no warning in PHP logs. memory_limit is irrelevant here. The cgroup memory.max is what bounds the process.

What actually bounds RSS

There is no single PHP-level setting that caps worker RSS. The real bounds are layered:

pm.max_requests (containment, not a cap). The primary defense. After N requests, the worker finishes its current request, delivers the response, then self-terminates. The master spawns a replacement with a fresh memory footprint. This does not set a maximum RSS. It sets a maximum number of requests before recycling, which bounds how much cumulative growth can occur. A value of 0 (the default in many distributions) disables recycling entirely, allowing unbounded growth.

cgroup limits (the only hard OS-level bound). On systemd-managed hosts, systemctl set-property php-fpm.service MemoryMax=2G sets a hard ceiling on total RSS of all workers combined. When hit, the cgroup OOM killer fires. MemoryHigh=1.5G sets a soft limit that triggers kernel reclaim and throttling before the hard limit. This is the only mechanism that actually caps RSS regardless of what PHP or its extensions allocate. In containers, the equivalent is the cgroup memory.max set by the orchestrator.

OPcache memory_consumption (bounds the shared segment). This limits the size of the OPcache shared memory segment. It does not bound per-worker RSS directly, but it bounds one contributor to it. Since OPcache pages are shared, this is a single allocation, not a per-worker one.

The OOM killer (last resort). If nothing else bounds memory, the kernel OOM killer will. This is not a mechanism you configure. It is the failure mode you get when you did not configure the others.

There is no PHP-level equivalent of pm.max_memory that checks per-worker RSS after each request and recycles if it exceeds a threshold. A feature request exists as php/php-src issue 17661 but as of August 2026 it remains open with no merged implementation.

Signals to watch in production

How Netdata helps

• Per-process RSS tracking at per-second resolution catches the monotonic growth pattern that indicates a leak, even when memory_limit never fires. The trend matters more than the absolute value.
• cgroup memory metrics (memory.current, memory.max, memory.events.oom_kill) are collected natively, which is the signal that actually matters in containerized deployments where memory_limit is irrelevant.
• Correlation between per-worker RSS and pm.max_requests recycling shows whether recycling is bounding growth or whether the leak is fast enough to matter between recycles.
• OPcache memory usage and hit rate alongside FPM metrics distinguish OPcache-driven RSS inflation from extension-driven growth.
• Worker exit signals (SIGKILL vs SIGSEGV vs code 0) distinguish OOM kills from extension crashes from normal recycling.

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 memory leak: per-worker RSS climbing until the box runs out
• PHP-FPM monitoring checklist: the signals every production pool needs
• PHP-FPM monitoring maturity model: from survival to expert
• PHP-FPM workers OOM-killed: “child N exited on signal 9 (SIGKILL)” and the memory cliff
• PHP-FPM request duration climbing: spotting stuck and outlier workers
• PHP-FPM request_terminate_timeout: stopping stuck requests from eroding the pool