Un worker PHP-FPM alcanzó 25,4 GB de RAM.
Diagnóstico de un OOM en producción y contención del consumo por proceso.
Contexto
Servidor de producción con 31 GB de RAM y 14 GB de swap. El incidente se registró el 23 de septiembre de 2026.
Problema
Un proceso PHP-FPM alcanzó un pico de 25,4 GB de memoria y 5,3 GB de swap. El kernel ejecutó el OOM killer; los logs de acceso mostraron respuestas 500/502.
Intervención
Correlación de logs del kernel y PHP-FPM. Instalación de un guard por RSS con límite de 1536 MiB y registro de PID, URI e IP para investigar el origen.
La actuación se divide en contención y análisis causal: limitar el proceso evita que el mismo patrón de consumo agote el host, mientras el log permite localizar la petición y revisar el código. Un guard debe coordinarse con el ciclo de workers y no reemplaza límites y observabilidad del pool.
Resultado observado
El guard registró la terminación de un worker con 1644,2 MiB RSS. El estado del pool se verificó después de la intervención.
Límites y siguiente paso
La contención limita el impacto, pero no elimina la causa de la asignación de memoria. Falta analizar las peticiones asociadas a /index.php y validar la solución en el tiempo.
Para verificar estabilidad se propone revisar terminaciones del guard, errores 5xx, RSS por worker, consumo de swap y latencia bajo carga comparable. No hay datos suficientes para afirmar que el problema desapareció definitivamente o atribuir una reducción porcentual de incidentes.