ID de la causa mem-leak · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
La memoria que no se libera se acumula poco a poco y, al cabo de unos días, termina en un GC excesivo, swap o un cierre forzado.
Por qué No se libera la información de los personajes que ya se desconectaron ni los manejadores de eventos (event handlers) → Efecto La memoria libre baja a lo largo de varios días → En pantalla Va bien justo después del mantenimiento, cada día hay más lag y al final el servidor se cae
Cuanto más tiempo lleva encendido, Horas pico de la noche
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Analizar volcados del heap (heap dumps), hacer pruebas de carga de larga duración.
Tareas (Equipo de infraestructura)
Monitorear la tendencia del uso de memoria por proceso y configurar alertas.
En el gráfico
Subida gradual · Memoria del proceso (RSS), heap justo después del GC
Dónde mirar
Memoria del proceso del servidor del juego (RSS de pidstat -r) a lo largo de varios días; en servidores con GC, el heap que queda justo después del GC. En Java, el valor posterior al GC de los dos usos (antes y después) que aparecen en las líneas de -Xlog:gc; en .NET, el tamaño del heap tras el GC en dotnet-counters (dotnet.gc.last_collection.heap.size desde .NET 9; GC Heap Size en .NET 8 y anteriores)
Se confirma si
El heap que queda justo después del GC (la línea base) sube cada día desde el reinicio y no baja ni siquiera de madrugada, cuando hay pocos jugadores
Se descarta si
Si la línea base del heap es plana y solo sube el RSS, apunta a fragmentación (mem-fragment) o a memoria nativa. Si sube y baja con el número de jugadores, es uso normal
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Si el servidor se reinicia cada semana en el mantenimiento programado, la fuga queda oculta y puede pasar mucho tiempo sin detectarse. Es habitual que aparezca de repente cuando se aplaza un mantenimiento o cuando un evento aumenta el número de jugadores.
Fuentes
Troubleshoot Memory LeaksOracle Si la ejecución se vuelve cada vez más lenta, hay que sospechar de una fuga; al final la memoria se agota y el proceso termina de forma anómala. El dato clave para analizar una fuga es el volcado del heap
Debug a memory leak in .NET.NET Aunque haya GC, si se siguen referenciando objetos innecesarios hay fuga, con pérdida de rendimiento y OutOfMemoryException. Revisar la tendencia de la memoria y analizar volcados
Garbage Collector ImplementationOracle Las líneas de -Xlog:gc tienen el formato “uso antes del GC->uso después del GC (tamaño del heap)”
dotnet-counters diagnostic tool.NET Desde .NET 9 se muestra como dotnet.gc.last_collection.heap.size; en .NET 8 y anteriores, como GC Heap Size