ID da causa mem-leak · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Memória que não é liberada vai se acumulando aos poucos e, depois de alguns dias, faz o GC rodar sem parar, causa swap ou leva a um encerramento forçado.
Por quê Dados de personagens que já saíram do jogo e event handlers não são liberados → Efeito A memória livre diminui ao longo de vários dias → Na tela Tudo normal logo após a manutenção, mais lag a cada dia e, no fim, o servidor cai
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Analisar heap dumps, fazer testes de carga de longa duração.
O que fazer (Equipe de infraestrutura)
Monitorar a tendência do uso de memória por processo e criar alertas.
No gráfico
Subida lenta · Memória do processo (RSS), heap logo após o GC
Onde olhar
Ver a memória do processo do servidor do jogo (RSS no pidstat -r) ao longo de vários dias e, em servidores com GC, o heap que sobra logo após o GC. No Java, o valor de depois do GC nas linhas do -Xlog:gc, que mostram o uso antes e depois; no .NET, o tamanho do heap após o GC no dotnet-counters (dotnet.gc.last_collection.heap.size a partir do .NET 9, GC Heap Size no 8 e anteriores)
Confirma se
O heap que sobra logo após o GC (linha de base) sobe a cada dia desde o reinício e não desce nem de madrugada, com poucos jogadores
Descarta se
Linha de base do heap estável, mas só o RSS sobe: fragmentação (mem-fragment) ou memória nativa. Sobe e desce com o número de jogadores: uso normal
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com a manutenção semanal reiniciando o servidor, o vazamento fica escondido e passa muito tempo sem ser descoberto. Ele costuma aparecer de repente quando uma manutenção é adiada ou quando um evento aumenta o número de jogadores.
Fontes
Troubleshoot Memory LeaksOracle Se a execução fica cada vez mais lenta, suspeite de vazamento; no fim a memória acaba e o processo termina de forma anormal. O principal material para analisar vazamentos é o heap dump
Debug a memory leak in .NET.NET Mesmo com GC, continuar referenciando objetos desnecessários é vazamento e causa queda de desempenho e OutOfMemoryException. Verificação da tendência de memória e análise de dumps
Garbage Collector ImplementationOracle As linhas do -Xlog:gc têm o formato “uso antes do GC->uso depois do GC (tamanho do heap)”
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como dotnet.gc.last_collection.heap.size; no .NET 8 e anteriores, como GC Heap Size