ID de la causa in-deploy · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si al reiniciar un servidor para actualizarlo no se trasladan sus conexiones, los jugadores que estaban en él se desconectan, y los guardados justo antes del cierre y las reconexiones llegan todos de golpe.
Por qué Se despliega un hotfix y se reinician los servidores uno tras otro → Efecto Se apaga sin trasladar las conexiones a otro servidor, y los guardados de todos los jugadores de ese servidor se concentran en la BD → En pantalla Desconexión sin aviso, avalancha de reconexiones
De vez en cuando, al azar, Al conectar o tras un mantenimiento
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Implementar una función de drenaje (bloquear solo las conexiones nuevas y esperar a que salgan los jugadores que ya están), trasladar personajes a otro servidor, repartir los guardados antes del cierre, avisar de que el servidor está listo solo después de cargar la caché y terminar el calentamiento del JIT tras reiniciar, y en la recarga en caliente (hot reload) leer los datos de antemano en otro hilo y sustituirlos de una vez entre ticks.
Tareas (Equipo de infraestructura)
Hacer que la herramienta de despliegue reinicie los servidores de uno en uno esperando al drenaje, que el servidor reiniciado reciba tráfico solo tras confirmar que está listo (calentamiento terminado), anunciar la hora del despliegue.
Cifras de referencia
Con 5,000 jugadores en un servidor, llegan 5,000 guardados a la BD en los pocos segundos antes del cierre.
En el gráfico
Desconexión masiva · Conexiones por servidor, escrituras en la BD
Dónde mirar
Superponer el registro de la herramienta de despliegue (hora de reinicio de cada servidor) como líneas verticales (anotaciones) sobre los gráficos de conexiones, desconexiones, escrituras en la BD y solicitudes de inicio de sesión
Se confirma si
Las conexiones de cada servidor caen en picado una tras otra a la hora de su reinicio, con un pico de escrituras en la BD justo antes y de solicitudes de inicio de sesión justo después
Se descarta si
Si la hora de las desconexiones no coincide con el registro de despliegues y reinicios, apunta a un crash del servidor o a los equipos de red
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Justo después de volver a arrancar, el servidor también va lento durante unos minutos. La caché está vacía y se acumulan las consultas a la BD, y en los servidores Java o C# todavía no ha terminado el proceso que optimiza el código mientras se ejecuta (calentamiento del JIT), así que el mismo trabajo tarda más. Recargar scripts o tablas de datos sin apagar el servidor (hot reload) también detiene el tick mientras se leen, lo que provoca una pausa breve.
Fuentes
Site Reliability Engineering, Chapter 20: Load Balancing in the DatacenterGoogle El servidor que recibe SIGTERM entra en estado lame duck, desvía las solicitudes nuevas a otros servidores y solo termina las que están en curso; en los primeros minutos tras reiniciar consume más recursos porque el JIT aún no ha optimizado el código, así que recibe tráfico solo después del calentamiento
Liveness, Readiness, and Startup ProbesKubernetes Con una readiness probe, no se envía tráfico hasta terminar de establecer conexiones, cargar archivos y calentar la caché