One PHP-FPM worker reached 25.4 GB of RAM.
Investigating a production OOM and containing per-process memory usage.
Context
Production server with 31 GB RAM and 14 GB swap. The incident was recorded on September 23, 2026.
Problem
A PHP-FPM process reached 25.4 GB memory and 5.3 GB swap. The kernel invoked the OOM killer; access logs showed 500/502 responses.
Intervention
Correlated kernel and PHP-FPM logs. Installed an RSS guard with a 1536 MiB threshold, recording PID, URI and client IP for investigation.
Work is split into containment and root-cause analysis: limiting a process prevents the same usage pattern from exhausting the host, while logs identify the request for code review. A guard must respect worker lifecycle and does not replace pool limits and observability.
Observed outcome
The guard recorded termination of a worker at 1644.2 MiB RSS. Pool health was checked following intervention.
Limits and next step
Containment reduces impact but does not resolve the allocation root cause. Requests associated with /index.php still require investigation and the fix needs observation over time.
To verify stability, review guard terminations, 5xx errors, per-worker RSS, swap usage and latency under comparable load. Available data cannot establish permanent resolution or a percentage reduction in incidents.