Quando um evento cria objetos temporários em grande quantidade, o GC roda com muito mais frequência que o normal.
Por quê Drops de itens, logs de combate e recompensas de evento fazem explodir o número de objetos temporários → Efeito O GC roda várias vezes mais, e objetos que ainda não foram descartados passam para a geração old, o que também antecipa o Full GC → Na tela Engasgos periódicos só durante eventos
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar object pool e buffers reutilizáveis, fazer profiling de alocação.
No gráfico
Sobe com a carga · Número de GCs, taxa de alocação
Onde olhar
Contar os GCs por minuto pelo log do GC (Java -Xlog:gc, Go GODEBUG=gctrace=1); no .NET, ver o volume alocado e o número de GCs no dotnet-counters (dotnet.gc.heap.total_allocated e dotnet.gc.collections a partir do .NET 9, Allocation Rate e Gen 0 GC Count no 8 e anteriores). Sobrepor ao número de jogadores simultâneos e aos horários dos eventos
Confirma se
Quando o evento começa, a taxa de alocação e o número de GCs crescem mais rápido que o número de jogadores, e as pausas curtas ficam frequentes. Quando o evento termina, tudo volta ao normal
Descarta se
Número de GCs estável, mas cada pausa mais longa: aumentaram os dados vivos (mem-gc-thrash, mem-leak)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
Garbage Collector ImplementationOracle Quando a geração young enche, roda um minor GC; parte dos objetos sobreviventes vai para a geração old, e quando a old enche o heap inteiro é coletado (bem mais demorado que o minor); -Xlog:gc registra uma linha por GC
A Guide to the Go Garbage CollectorGo Quanto maior a taxa de alocação, mais frequentes os ciclos de GC; GODEBUG=gctrace=1 gera o trace do GC
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como dotnet.gc.heap.total_allocated e dotnet.gc.collections; no .NET 8 e anteriores, como Allocation Rate e Gen 0 GC Count