PHP-FPM sizing pm.max_children: by memory, not by CPU cores

pm.max_children is the hard ceiling on concurrent request processing in a PHP-FPM pool. Each worker handles exactly one request at a time. Once all workers are busy, new requests queue in the socket backlog. Once the backlog fills, the kernel drops connections and users see 502 errors.

The common sizing mistake is anchoring this number to CPU core count. Teams pick 4 workers for a 4-core box, or 8 for an 8-core box, and assume they have sized correctly. They have not. PHP-FPM workers spend most of their lifetime blocked on I/O: database queries, external API calls, filesystem reads, session locks. While a worker waits on a slow database response, it holds a process slot but uses essentially zero CPU. A 4-core machine can run 50 to 200 workers if memory allows.

The binding constraint is memory. This guide covers the correct memory-based formula, why naive RSS overstates per-worker cost, and the companion settings that keep the pool stable.

What it is and why it matters

pm.max_children is mandatory in every PHP-FPM pool configuration. It defines the maximum number of child processes the master may spawn, regardless of process manager mode (static, dynamic, or ondemand). It is the one number that directly bounds concurrent request capacity.

Getting it wrong in either direction has consequences:

• Too low: workers exhaust during traffic bursts, requests queue, latency spikes, and the pool cannot absorb demand surges. You leave capacity on the table while RAM sits idle.
• Too high: aggregate worker footprint exceeds available RAM. The kernel begins swapping, latency explodes because PHP’s memory access patterns are brutal under swap, and the OOM killer eventually fires, taking out workers or the master with no warning.

Memory degradation is a nonlinear cliff. Performance looks stable until swapping begins, then latency spikes dramatically, then the OOM killer strikes. There is no graceful middle ground. Sizing by memory, with a safety buffer, is the only way to stay off that cliff.

The memory-based sizing formula

The total memory consumed by all workers at peak concurrency must fit within the RAM budget allocated to PHP-FPM. That budget is not full system RAM. The OS needs page cache and buffers, and other services coexist on the host.

# Memory-safe max_children calculation
max_children = (total_RAM * 0.7 - co-located_overhead) / avg_worker_PSS

The 0.7 multiplier reserves 30% of total RAM for the OS page cache, buffers, and any co-located services. On a host with 8 GB of RAM, that leaves roughly 5.6 GB for PHP-FPM before subtracting explicit co-located overhead. On a host where PHP-FPM shares the machine with MySQL, Redis, and a web server, subtract their typical footprints from the 5.6 GB before dividing.

flowchart TD
    A[Total system RAM] --> B[Reserve 30% for OS and page cache]
    B --> C[RAM budget for PHP-FPM]
    C --> D[Measure avg per-worker memory]
    E[Use PSS not naive RSS] --> D
    D --> F[Divide budget by per-worker memory]
    F --> G[Result is memory-safe max_children]
    G --> H[Set pm.max_requests as leak defense]

A typical PHP application worker sits between 30 and 200 MB depending on framework weight, extensions, and request patterns. On a 4-core, 8 GB host with average worker PSS of 50 MB and 1 GB of co-located services:

# Worked example: 8GB host, 1GB co-located services, 50MB avg PSS
budget = (8192 * 0.7) - 1024 = 4710 MB
max_children = 4710 / 50 = 94 workers

Ninety-four workers on 4 cores. That is correct if the workload is I/O-bound, which most web PHP workloads are.

Measuring per-worker memory honestly (the RSS trap)

The most common error in this calculation is using naive RSS. ps and /proc/[pid]/status report VmRSS per process, but PHP-FPM workers are forked from the master and share a large read-only memory segment, most notably the OPcache shared memory. The kernel maps those shared pages once, but ps counts them in every worker’s RSS.

Naive RSS can overstate actual per-worker memory by 30 to 50%. A worker reporting 60 MB of RSS might have a PSS (Proportional Set Size) of only 35 MB once shared pages are divided proportionally.

Measure PSS instead. Two approaches:

# Average RSS of all workers (KB) - inflated by shared opcache pages
ps -eo pid,rss,cmd | grep '[p]hp-fpm' | grep -v master | awk '{sum+=$2; count++} END {print sum/count " KB avg"}'

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

The smem output gives you both columns side by side. Use the PSS column for capacity math. If smem is not available, read /proc/[pid]/smaps_rollup and use the Pss field.

Second caveat: measure workers under realistic load, not idle workers. Workers grow as they handle requests and populate internal caches, autoloader state, and connection pools. A freshly forked worker looks small. The number you want is the steady-state average across workers that have served a few hundred requests.

Third caveat: if your application has a memory leak, the average trends upward over time. pm.max_requests is the defense (see below), but for sizing purposes measure after workers have hit their recycling point at least once so you capture the post-warmup footprint.

Where this shows up in production

Bare metal or VM, single pool. Measure PSS, apply the formula, verify against the 70% RAM budget.

Multiple pools. Each pool has its own pm.max_children and its own workers. The memory budget must be divided across all pools. A memory leak in one pool does not affect others, but they all compete for the same RAM. Size each pool independently, then sum the totals and confirm the aggregate stays within budget.

Containers (Docker, Kubernetes). The cgroup memory limit is the hard ceiling, not host RAM. PHP-FPM does not natively read cgroup limits. You must manually calculate pm.max_children from the container memory limit minus a buffer for the OS page cache and any sidecar processes. The OOM killer operates at the cgroup level and can kill the master process with no warning in the PHP-FPM logs. Monitor cgroup-level memory, not just host memory.

Shared host with MySQL, Redis, web server. The 0.7 multiplier assumes PHP-FPM is the dominant workload. If it shares the host, subtract the typical footprint of each co-tenant explicitly before dividing.

Dynamic mode under burst traffic. In pm = dynamic, the process manager scales workers between pm.min_spare_servers and pm.max_children based on demand. The scaling is reactive, not predictive. Under a sudden burst, the master forks workers as fast as it can, but if pm.max_children is set near the memory ceiling, a burst that spawns many workers at once can exhaust RAM before the master throttles. The memory budget must accommodate worst-case concurrency, not just average. Many operators prefer pm = static in production precisely because it fixes memory usage and eliminates the spawn spike at the cost of constant memory consumption.

Companion settings

Sizing pm.max_children correctly is necessary but not sufficient. Two related settings keep the pool from drifting into trouble.

pm.max_requests forces a worker to self-terminate after serving N requests, after finishing its current request and delivering the response. The master spawns a replacement. This is the primary defense against memory leaks in application code and extensions. A value of 500 to 1000 is typical. The default is 0, meaning unlimited: workers accumulate leaked memory without bound, RSS trends upward, and the OOM cliff approaches. Setting pm.max_requests is near-zero cost. Leaving it disabled is unjustifiable.

PHP memory_limit constrains per-request heap allocation, not cumulative worker RSS. A worker handling many requests can grow beyond memory_limit because extensions (ImageMagick, libxml, database drivers) allocate outside the PHP heap and are not bound by it. Do not treat memory_limit as a substitute for proper pm.max_children sizing. The relationship to watch: a high memory_limit combined with a high pm.max_children means each worker can balloon during a heavy request, pushing the aggregate closer to the ceiling. Size for the steady-state PSS, then verify that peak per-request allocation does not break the budget.

Signals to watch in production

How Netdata helps

Netdata’s PHP-FPM collector pulls status page metrics at per-second resolution. Saturation events unfold in seconds, and slower polling misses transient queue buildups. For sizing work specifically:

• Per-worker RSS and aggregate FPM memory appear alongside system RAM and swap, so you can watch the budget relationship and catch the moment PHP-FPM starts pressing the ceiling.
• The active processes and idle processes counters let you confirm whether the pool is actually using the capacity you provisioned, or whether you over-allocated.
• Anomaly detection flags upward drift in per-worker memory early, before a leak pushes the aggregate over budget and triggers the OOM cliff.
• Container deployments get cgroup-level memory metrics correlated with FPM pool metrics, so you can size pm.max_children against the actual cgroup ceiling rather than host RAM.
• The max children reached counter rate, combined with listen queue depth, tells you whether a given pm.max_children value is genuinely constraining throughput or comfortably absorbing traffic.

Related guides

• 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 “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 worker exhaustion: all workers busy and requests piling into the backlog