OOM killer Out-of-memory killer

ID de la causa so-oom · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)

Abrir la ficha interactiva con gráficos y simulaciones →

Cuando Linux se queda sin memoria, elige el proceso que más memoria usa y lo mata a la fuerza. Casi siempre es el servidor del juego.

Por qué Memoria agotada por una fuga o un pico de uso, o límite de memoria del contenedor alcanzado → Efecto El kernel cierra a la fuerza el proceso del servidor del juego → En pantalla Desconexión simultánea de todos los jugadores de ese servidor, con posible rollback del progreso reciente

Síntomas: Desconexión, Acción perdida / rollback
Factores: Detención
A quién afecta: Todo el servidor
Cuándo: Cuanto más tiempo lleva encendido, Cuando se junta mucha gente
Responsable: Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo): Corregir las fugas, fijar un tope de uso de memoria y un procedimiento que guarde y cierre el servidor de forma ordenada al acercarse a él.
Tareas (Equipo de infraestructura): Configurar alertas de memoria, ajustar el límite de memoria del contenedor al uso real, ajustar el orden en que se matan los procesos (oom_score_adj).
Cifras de referencia: En el log del kernel (dmesg) queda “Out of memory: Killed process”, y en Kubernetes se ve como OOMKilled. Windows no tiene OOM killer; muchas veces la asignación de memoria falla y el servidor se cae con un error.
En el gráfico: Desconexión masiva · Número de conexiones, uso de memoria
Dónde mirar: Registro “Out of memory: Killed process” en dmesg; en Kubernetes, OOMKilled en el estado del pod; en cgroup v2, aumento de oom_kill en memory.events; todo cruzado con la hora de las desconexiones
Se confirma si: A la hora de la desconexión masiva hay un registro de que se mató el proceso del servidor del juego, y hasta justo antes el uso de memoria subió hasta el límite
Se descarta si: Si no hay registro de OOM pero el proceso murió, revisar los logs de crash y el core dump (ver “Crash del servidor”)
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

mm/oom_kill.c (Linux v6.12) Linux kernel
El cálculo da la puntuación más alta al proceso que más memoria usa (teniendo en cuenta oom_score_adj); al matarlo se registra “Out of memory: Killed process …”
Assign Memory Resources to Containers and Pods Kubernetes
Si un contenedor sigue usando memoria por encima de su límite (limit), se termina y su estado aparece como OOMKilled
Pushing the Limits of Windows: Virtual Memory Microsoft
En Windows, al alcanzar el límite de confirmación (commit limit), fallan las asignaciones que confirman memoria, lo que puede provocar errores en las aplicaciones o fallos del sistema
Control Group v2 Linux kernel
oom_kill de memory.events: número de procesos que el OOM killer mató en este cgroup

Ver también

Misma capa: L7 SO del servidor (kernel)

Causas de otras capas con el mismo síntoma (Desconexión)

Fuga de memoria en el cliente L1 Proceso del juego en el cliente
Crash del cliente L1 Proceso del juego en el cliente
Escaneos del módulo anti-cheat L1 Proceso del juego en el cliente
Aplicación móvil enviada a segundo plano L2 SO y dispositivo del cliente
Cambio Wi-Fi ↔ LTE/5G L2 SO y dispositivo del cliente
Procesamiento limitado con la ventana minimizada o sin foco L2 SO y dispositivo del cliente
Interferencias de programas de overlay L2 SO y dispositivo del cliente
Expiración del mapeo NAT L3 Red doméstica

Ver la ficha interactiva con gráficos y simulaciones