Avalancha de asignaciones Allocation storms

ID de la causa mem-alloc · Responsable principal Desarrollo de servidor (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Si durante un evento se crean muchísimos objetos temporales, el GC se ejecuta mucho más a menudo que de costumbre.

Por qué Explosión de objetos temporales por los drops de objetos, los logs de combate y las recompensas de eventos → Efecto El GC se ejecuta varias veces más a menudo, y los objetos que no llegan a descartarse a tiempo pasan a la generación vieja (Old), lo que también adelanta el Full GC → En pantalla Tirones periódicos solo durante los eventos

Síntomas: Tirones, Congelamiento
Factores: Detención
A quién afecta: Todo el servidor, Una zona o un canal
Cuándo: Cuando se junta mucha gente
Responsable: Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Usar pools de objetos y búferes reutilizables, perfilar las asignaciones.
En el gráfico: Sube con la carga · Número de GC, velocidad de asignación
Dónde mirar: Contar los GC por minuto en el log del GC (Java -Xlog:gc, Go GODEBUG=gctrace=1); en .NET, la cantidad asignada y el número de GC en dotnet-counters (dotnet.gc.heap.total_allocated y dotnet.gc.collections desde .NET 9; Allocation Rate y Gen 0 GC Count en .NET 8 y anteriores). Todo superpuesto a los jugadores conectados y a la hora de los eventos
Se confirma si: Al empezar un evento, la velocidad de asignación y el número de GC suben más deprisa que el número de jugadores, y las pausas cortas se vuelven frecuentes. Al terminar el evento todo vuelve a la normalidad
Se descarta si: Si el número de GC no cambia pero cada pausa dura más, han aumentado los datos vivos (mem-gc-thrash, mem-leak)
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

Garbage Collector Implementation Oracle
Cuando la generación joven (Young) se llena hay un minor GC, y parte de los objetos supervivientes pasa a la generación vieja (Old); cuando la vieja se llena, se recolecta todo el heap (mucho más lento que un minor); -Xlog:gc escribe una línea por GC
A Guide to the Go Garbage Collector Go
Cuanto mayor es la velocidad de asignación, más frecuentes son los ciclos de GC; GODEBUG=gctrace=1 imprime la traza del GC
dotnet-counters diagnostic tool .NET
Desde .NET 9 se muestra como dotnet.gc.heap.total_allocated y dotnet.gc.collections; en .NET 8 y anteriores, como Allocation Rate y Gen 0 GC Count

Ver también

Misma capa: L10 Memoria

Causas de otras capas con el mismo síntoma (Tirones)

Pico de frametime L1 Proceso del juego en el cliente
Recolección de basura (GC) en el cliente L1 Proceso del juego en el cliente
Carga síncrona y compilación de shaders en el hilo principal L1 Proceso del juego en el cliente
Almacenamiento lento que retrasa el streaming de assets L1 Proceso del juego en el cliente
Carga de renderizado de multitudes L1 Proceso del juego en el cliente
Búfer de interpolación ausente o demasiado corto L1 Proceso del juego en el cliente
Extrapolación excesiva (dead reckoning) L1 Proceso del juego en el cliente
Espiral de recuperación con timestep fijo L1 Proceso del juego en el cliente

Ver la ficha interactiva con gráficos y simulaciones