OOM killer Out-of-memory killer

ID da causa so-oom · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)

Abrir o card interativo, com figuras e simulações →

Quando a memória acaba, o Linux escolhe o processo que mais usa memória e o mata à força. Em geral, é o servidor do jogo.

Por quê Memória esgotada por vazamento ou pico de uso, ou limite de memória do contêiner atingido → Efeito O kernel encerra à força o processo do servidor do jogo → Na tela Todos naquele servidor sofrem desconexão ao mesmo tempo, e o progresso recente pode sofrer rollback

Sintomas: Desconexão, Ação perdida / rollback
Fatores: Paralisação
Quem é afetado: Servidor inteiro
Quando: Quanto mais tempo ligado, Quando junta muita gente
Responsável: Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento): Corrigir vazamentos, definir um teto de uso de memória e um procedimento que salva e encerra normalmente quando o uso chega perto dele.
O que fazer (Equipe de infraestrutura): Alertar sobre memória, ajustar o limite de memória do contêiner ao uso real, ajustar a ordem de quem é morto primeiro (oom_score_adj).
Números de referência: O log do kernel (dmesg) registra “Out of memory: Killed process”, e no Kubernetes aparece como OOMKilled. O Windows não tem OOM killer. Lá, o mais comum é a alocação de memória falhar e o servidor cair com erro.
No gráfico: Queda de conexões em massa · Conexões, uso de memória
Onde olhar: Registro “Out of memory: Killed process” no dmesg, status OOMKilled do pod no Kubernetes ou aumento de oom_kill em memory.events no cgroup v2, cruzados com o horário das desconexões
Confirma se: Há registro do processo do servidor do jogo sendo morto no momento da desconexão em massa, e o uso de memória vinha subindo até o limite logo antes
Descarta se: Sem registro de OOM, mas o processo caiu: ver o log de crash e o core dump em “Crash do servidor”
Como verificar: Ferramentas de infra (sem precisar do código do jogo)

Fontes

mm/oom_kill.c (Linux v6.12) Linux kernel
Calcula a pontuação para que o processo que mais usa memória fique com a mais alta (considerando oom_score_adj) e registra “Out of memory: Killed process …” ao encerrar
Assign Memory Resources to Containers and Pods Kubernetes
Se o contêiner continua usando memória além do limit, ele é encerrado e o status aparece como OOMKilled
Pushing the Limits of Windows: Virtual Memory Microsoft
No Windows, ao chegar ao limite de commit, as alocações que reservam memória falham, o que pode levar a erros no app ou a falhas do sistema
Control Group v2 Linux kernel
oom_kill em memory.events: número de processos mortos pelo OOM killer neste cgroup

Veja também

Mesma camada: L7 SO do servidor (kernel)

Mesmo sintoma (Desconexão) em outras camadas

Vazamento de memória no cliente L1 Processo do jogo no cliente
Crash do cliente L1 Processo do jogo no cliente
Verificações do anti-cheat (módulo de segurança do jogo) L1 Processo do jogo no cliente
App mobile em segundo plano L2 SO e dispositivo do cliente
Troca Wi-Fi ↔ LTE/5G L2 SO e dispositivo do cliente
Limitação de processamento com a janela minimizada ou inativa L2 SO e dispositivo do cliente
Interferência de programas de overlay L2 SO e dispositivo do cliente
Expiração do mapeamento NAT L3 Rede doméstica

Ver o card interativo, com figuras e simulações