$ guides / apache-httpd / apache-httpd-maxconnectionsperchild ▌

Operations Guides

Apache MaxConnectionsPerChild: bounding leaky modules by recycling children

The symptom usually arrives as a slow memory problem, not a clean Apache failure. Per-child RSS climbs for hours or days, total Apache memory grows linearly, swap starts to move, and then the kernel OOM killer begins shooting httpd children. The parent respawns them, the new children leak too, and the host enters a respawn and OOM loop.

When that pattern is present, MaxConnectionsPerChild 0 is often part of the story. The default value of 0 means children never recycle. A leaky module, or plain APR pool fragmentation in a long-lived prefork child, gets unlimited time to grow. Setting a finite value, commonly 5000 to 10000, forces each child to exit after handling that many connections so the parent can replace it with a fresh, smaller process.

This is a containment control, not a cure. It bounds leaked memory and reclaims fragmented allocator state, but it does not fix the module, PHP extension, Perl code, custom C module, or application pattern that is leaking. Used well, it converts a terminal memory leak into a controlled sawtooth. Used badly, especially with too low a value, it trades an OOM risk for fork churn, cold-cache respawns, and extra latency.

What this means

Apache recycles work through child processes. In prefork, each child handles one connection at a time and carries a full copy of the httpd address space, often 10 MB to 50 MB or more before heavy modules. With mod_php, per-child memory can be several times higher because the PHP runtime lives inside every httpd child. APR allocates per-connection and per-request memory from pools that are destroyed when the connection or request ends, but a long-lived child that serves many requests can still accumulate fragmentation and module state that is not fully returned.

MaxConnectionsPerChild exists to put a hard lifetime on that accumulation. Older configurations may use the former name MaxRequestsPerChild. The operational meaning is the same: after a child has handled enough work, Apache lets it finish and replaces it. The leaked or fragmented pages leave with the old process instead of staying resident until the next full restart.

flowchart LR
  req[Connections handled by child] --> pool[APR pools and module state]
  pool --> rss[Per-child RSS grows]
  rss --> limit{MaxConnectionsPerChild reached?}
  limit -- "no" --> req
  limit -- "yes" --> exit[Old child exits after draining]
  exit --> fresh[Parent forks fresh child]
  rss --> risk[Unbounded if value is 0]
  risk --> oom[Swap, OOM kills, respawn loop]

The important distinction is where the leak lives. If PHP runs inside httpd via mod_php on prefork, recycling httpd children also resets the PHP runtime embedded in those children. If PHP runs externally in PHP-FPM, recycling Apache children does not reclaim PHP-FPM worker memory. Do not copy prefork plus mod_php advice onto an event MPM plus PHP-FPM host without checking which process is actually growing.

Common causes

Cause	What it looks like	First thing to check
`MaxConnectionsPerChild 0` with a leaky module	Monotonic per-child RSS growth over hours or days, then swap and OOM kills	`ps -C httpd -o pid,rss --sort=-rss` or `ps -C apache2 ...` sampled over time
mod_php or mod_perl resident in prefork children	High baseline RSS, children get heavier with request count, reset after restart	Confirm MPM and whether PHP or Perl runs inside httpd
APR pool fragmentation in long-lived children	RSS ratchets upward even without a clear application leak	Compare fresh children to children that have served many connections
Worker pool sized beyond RAM	`MaxRequestWorkers` times observed RSS exceeds safe memory headroom	Recompute pool size from measured per-child RSS
Containment set too low	After the change, latency rises and children respawn constantly	Watch child spawn rate, uptime, first-request latency after respawn
Leak is outside Apache	httpd RSS is stable while PHP-FPM, a backend, or another service grows	Identify the growing process before tuning httpd

Quick checks

Use read-only checks first. Do not restart Apache as the opening move.

# Confirm the Apache parent and process name for this distro
pgrep -o 'httpd|apache2' | xargs -r ps -o pid,ppid,cmd -p

# Show per-child RSS, largest first
ps -C httpd -o pid,ppid,rss,vsz,args --sort=-rss 2>/dev/null || \
  ps -C apache2 -o pid,ppid,rss,vsz,args --sort=-rss

# Summarize count, average RSS, and worst child
( ps -C httpd -o rss= 2>/dev/null || ps -C apache2 -o rss= ) | \
  awk '{sum+=$1; count++; if($1>max)max=$1} END {if(count>0) printf "children=%d total_MB=%d avg_MB=%d max_MB=%d\n", count, sum/1024, sum/count/1024, max/1024}'

# Check worker pressure while memory grows (requires mod_status enabled and reachable from localhost)
curl -s http://localhost/server-status?auto | grep -E 'BusyWorkers|IdleWorkers|ServerUptimeSeconds|Total Accesses|Scoreboard:'

# Look for explicit saturation, crashes, and restart events
grep -E 'AH00484|AH00286|AH00161|Segmentation fault|resuming normal operations|caught SIGTERM' \
  /var/log/apache2/error.log /var/log/httpd/error_log 2>/dev/null | tail -50

# Check kernel evidence of OOM kills (dmesg usually needs root)
sudo dmesg 2>/dev/null | grep -iE 'oom|killed process.*(httpd|apache2)' | tail -20

# Check whether new connections are queueing while children are bloated (watch Recv-Q)
ss -ltn '( sport = :80 or sport = :443 )'

A useful quick read is the shape of RSS across children of different ages. Fresh children are small and older children are large: lifetime growth. One child is huge while peers are normal: a specific request pattern or module path. All children grow together after each deployment: application or extension behavior, not random fragmentation.

How to diagnose it

Confirm the MPM and module model. Use apachectl -V and the loaded module configuration to determine prefork, worker, or event, and whether PHP or Perl is embedded in httpd. The same RSS pattern means different things on prefork plus mod_php than on event plus PHP-FPM.
Establish that growth is per-child and time-based. Sample per-PID RSS several times over an hour. The leak pattern is a rising line per PID, not a one-time jump after a deploy or a traffic spike.
Correlate RSS with completed work. Use Total Accesses deltas from server-status?auto and compare against RSS growth. If children that complete more connections are consistently larger, lifetime recycling will bound them. If RSS jumps independently of served work, look for a specific endpoint, large request body, or module path.
Rule out worker exhaustion as the primary event. Check BusyWorkers, IdleWorkers, the scoreboard, listen Recv-Q, and AH00484. Memory leaks often coexist with saturation because bloated children lower the safe worker ceiling, but queuing alone is not proof of a leak.
Check crash and OOM evidence. Segfaults, OOM kills, and repeated respawns change the urgency. Occasional single-child crashes can be designed recovery. Repeated OOM kills mean memory accounting is already wrong.
Find the likely owner of the growth. Compare RSS growth by URL pattern or vhost where logs allow it. For PHP, review memory_limit, extensions, and application behavior. For mod_perl or custom modules, suspect retained globals, circular references, native allocations, or incomplete cleanup.
Choose a starting recycle value. If you have no measurement, start near 10000 for a leaky prefork plus mod_php or mod_perl deployment and tune down only if RSS still reaches unsafe levels before recycling. The 5000 to 10000 band is the usual operating range. Avoid dropping to hundreds unless you have measured that fork cost and cold-cache latency are acceptable.
Apply safely and verify. Run apachectl configtest, then use a graceful reload during a low-risk window. Remember that graceful reloads overlap old and new generations and can briefly raise memory. Verify afterward that RSS forms a sawtooth, child respawns are not constant, and latency did not regress.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Per-child RSS trend	Direct leak detector and recycling verifier	Monotonic growth per PID, or worst child more than 2x average
Total Apache RSS vs RAM	Determines real OOM risk	`MaxRequestWorkers` times observed RSS above 70 percent of RAM
Swap and OOM events	Late-stage confirmation of memory pressure	Any sustained Apache swap use, or OOM kills in `dmesg`
Child respawn rate after tuning	Shows whether the value is too low	Constant respawns, latency spikes after new children start
BusyWorkers and IdleWorkers	Bloated memory lowers safe capacity	IdleWorkers near zero while RSS is high
Scoreboard distribution	Distinguishes waiting workers from memory-only growth	Many `W` from backend waits versus normal states with rising RSS
Request latency	Recycling should not create user-visible cost	P95 rises after each respawn wave or after lowering the value
Worker-limit messages and listen `Recv-Q`	Confirms saturation if leak reduces effective workers	`AH00484`/`AH00286`/`AH00161` appears, or Recv-Q stays above 0 with high utilization

Fixes

Bound the leak with a finite child lifetime

Set MaxConnectionsPerChild in the server or MPM configuration, not as a substitute for fixing code. A common starting point for prefork with embedded PHP or Perl is:

<IfModule mpm_prefork_module>
  MaxConnectionsPerChild 10000
</IfModule>

Start at 10000 when you need containment but do not yet know the leak rate. Move toward 5000 if children still reach dangerous RSS before recycling. Move upward if respawn cost is visible and memory headroom is comfortable. The right value is the highest one that keeps worst-case RSS safely inside memory while adding no measurable fork or warmup penalty.

Validate the exact file and included config layout on your distribution before editing. Run apachectl configtest first. Prefer graceful reload over hard restart, but plan for temporary old plus new child overlap during the reload.

Reclaim memory only where the leak actually lives

If mod_php or mod_perl is inside httpd, recycling httpd children resets that embedded runtime. If PHP is in PHP-FPM, tune and recycle PHP-FPM workers separately; do not expect httpd child recycling to shrink external PHP processes. The same logic applies to backends behind mod_proxy: Apache can shed its own per-connection state, but it cannot fix a leaking application server.

Resize the worker pool against measured memory

Recycling children does not make an oversized MaxRequestWorkers safe. Compute the ceiling from measured RSS: worst-case Apache memory is approximately MaxRequestWorkers times maximum observed child RSS, and that number should stay below about 70 percent of RAM. For prefork plus mod_php, initial estimates of 50 MB to 100 MB per child are only a starting point. Measure on the real host.

If memory is tight, the safer sequence is usually: bound child lifetime, reduce MaxRequestWorkers to match real RSS, then remove the leak. Raising the worker limit while children are still growing makes the OOM event larger, not later.

Treat too-low values as a production regression

After lowering MaxConnectionsPerChild, watch for a new failure mode: frequent child respawns. Each fresh child repeats module initialization and starts with cold process state. Constant fork churn and cold-cache respawns are the trade-off when the value is too low. If P95 latency, CPU, or spawn rate worsens after the change, raise the value and attack the leak directly.

Remove the root cause

Use recycling to buy time, then isolate the leaker. Compare RSS growth by endpoint, vhost, or module path. For PHP, check application allocations, extensions, and memory_limit. For mod_perl, look for retained globals and interpreter state. For custom C modules, audit APR pool lifetime and native allocations. If a specific extension or module is implicated, upgrading, replacing, or moving that workload out of httpd children is the real fix.

Prevention

Set an explicit lifetime on risky deployments. For prefork with mod_php or mod_perl, do not leave MaxConnectionsPerChild at 0 by default. Choose a measured finite value and document why.
Track RSS as a time series. A one-off ps snapshot misses the pattern. Alert on trend: per-child RSS slope, worst child versus average, and total Apache RSS versus RAM.
Keep memory headroom explicit. Recompute MaxRequestWorkers whenever modules, PHP version, framework, or traffic mix changes. Per-child RSS is a capacity input, not an afterthought.
Watch the cost of recycling. After any change, monitor child spawn rate, restart and uptime signals, P95 latency, CPU, and first-request slowdowns after respawn.
Separate embedded and external runtimes. Know whether PHP, Perl, Python, or application logic runs inside httpd or in a separate service before applying child-recycling advice.
Fix leaks during normal hours. Use containment to avoid paging, then schedule the actual module or application investigation before the sawtooth becomes normal and invisible.

How Netdata helps

Netdata charts per-process and per-child RSS over time, which turns “Apache feels heavy” into a visible leak slope and shows whether recycling creates a clean sawtooth.
Correlating total httpd memory with system RAM, swap, and OOM events helps separate a controlled recycling pattern from an approaching kernel kill loop.
BusyWorkers, IdleWorkers, and scoreboard state can be read next to memory, so you can tell bloated-but-idle children from a true worker exhaustion event.
Latency, request rate, 5xx rate, AH00484, and listen backlog signals reveal when a too-low recycle value starts costing users through respawn churn.
Restart and uptime signals make it easier to connect RSS drops to child recycling, graceful reloads, crashes, or OOM respawns.
Netdata’s Apache HTTP Server monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

The Netdata solution

Apache HTTP Server monitoring with Netdata

Netdata monitors Apache HTTP Server with per-second metrics from mod_status, pre-built dashboards, and ML-powered anomaly detection. Watch busy versus idle workers and the scoreboard state mix, requests per second, bytes served per second, and request processing duration alongside the rest of your stack, so you catch the worker-exhaustion, slow-backend, and memory incidents in these runbooks before they page anyone.

See web server monitoring → Start monitoring free