Libro blanco del lag en juegos › L10 Memoria

Fragmentación de memoria Heap fragmentation

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

Abrir la ficha interactiva con gráficos y simulaciones →

Si al asignar y liberar memoria una y otra vez el espacio libre queda partido en trozos pequeños, el proceso ocupa mucha más memoria de la que realmente usa.

Por qué Varios hilos asignan y liberan durante mucho tiempo bloques de memoria de tamaños muy distintos → Efecto El espacio libre queda disperso en trozos pequeños que no se pueden devolver al SO, y el uso sigue creciendo como si fuera una fuga → En pantalla Cuanto más tiempo lleva encendido, más lento va por el swap y la falta de memoria, hasta que se cierra a la fuerza

Síntomas

Cámara lenta, Desconexión

Factores

Detención

A quién afecta

Todo el servidor

Cuándo

Cuanto más tiempo lleva encendido

Responsable

Responsable principal Desarrollo de servidor (Equipo de desarrollo)

Tareas (Equipo de desarrollo)

Usar pools de memoria por tamaño y asignadores resistentes a la fragmentación (jemalloc, mimalloc, etc.).

En el gráfico

Subida gradual · Memoria del proceso (RSS)

Dónde mirar

Levantar dos servidores con la misma build y, solo en uno, reducir el número de arenas de glibc con la variable de entorno MALLOC_ARENA_MAX o cambiar a otro asignador como jemalloc; comparar durante varios días el RSS de pidstat -r

Se confirma si

Con un número parecido de jugadores y entidades, solo en el servidor modificado el RSS deja de crecer o baja mucho

Se descarta si

Si sube igual después de cambiar de asignador: memoria que no se libera (mem-leak)

Se verifica con

Con herramientas de infraestructura (no hace falta código del juego)

Para saber más

Tiene el mismo aspecto que una fuga, pero el análisis del heap no muestra ningún punto de fuga. El asignador predeterminado de Linux (glibc) lo sufre especialmente en servidores con muchos hilos, y a veces basta con cambiar de asignador para reducir mucho el uso de memoria.

Fuentes

1. mallopt(3) — Linux manual page Linux man-pages
   Para reducir la contención entre hilos, glibc malloc crea arenas hasta un múltiplo del número de CPU, y cuantas más arenas, más memoria usa (se limita con M_ARENA_MAX, también configurable con la variable de entorno MALLOC_ARENA_MAX)
2. jemalloc memory allocator jemalloc
   Implementación de malloc de propósito general centrada en evitar la fragmentación y escalar con la concurrencia
3. pidstat(1) — Linux manual page sysstat
   -r: RSS por proceso (memoria realmente cargada en la RAM)

Ver también

Misma capa: L10 Memoria

• Pausa stop-the-world del GC en el servidor
• Pausa del GC en el motor de scripts
• Avalancha de asignaciones
• Fuga de memoria
• Thrashing del GC (heap casi lleno)
• Swap
• Fallo de caché
• Acceso a memoria NUMA remota

Causas de otras capas con el mismo síntoma (Cámara lenta)

• Espiral de recuperación con timestep fijo L1 Proceso del juego en el cliente
• Desbalance del balanceador de carga y health checks erróneos L5 Equipos de red del centro de datos
• Exceso de hilos y cambios de contexto L7 SO del servidor (kernel)
• Throttling de CPU en contenedores (cuota de CFS) L7 SO del servidor (kernel)
• Picos de latencia por la gestión de energía del servidor (C-states, escalado de frecuencia) L7 SO del servidor (kernel)
• Tareas programadas L7 SO del servidor (kernel)
• Cambios de rendimiento tras actualizar el SO, el kernel, los drivers o el firmware L7 SO del servidor (kernel)
• Envíos bloqueantes por clientes lentos L8 Sockets y protocolos

Ver la ficha interactiva con gráficos y simulaciones