Desfase de reloj entre servidores Clock skew between servers
ID de la causa in-clock-skew · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Si cada servidor tiene un reloj un poco distinto, las comprobaciones de cooldowns, buffs y comienzos de evento no coinciden entre servidores.
Por qué El reloj de un servidor cuya sincronización horaria se detuvo se desfasa de cientos de ms a varios segundos respecto a los demás → Efecto Si se pasan horas absolutas entre servidores, como la hora en que termina un buff, las comprobaciones no coinciden → En pantalla Tras moverse a otro servidor, un buff desaparece o el cooldown vuelve a empezar
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Pasar entre servidores el tiempo restante, sin usar horas absolutas.
Tareas (Equipo de infraestructura)
Vigilar la sincronización horaria (NTP, chrony), poner alertas por diferencia de reloj entre servidores.
Cifras de referencia
Con la sincronización horaria (NTP, chrony) funcionando, los servidores de un mismo centro de datos suelen estar a pocos ms entre sí. Si la sincronización se detiene, o si un servidor virtual se queda detenido mucho tiempo y luego se reanuda, la diferencia llega a cientos de ms o varios segundos.
En el gráfico
Subida gradual · Desfase (offset) del reloj por servidor
Dónde mirar
Reunir y comparar, servidor por servidor, los campos de chronyc tracking System time (diferencia entre el reloj del sistema y el reloj NTP), Last offset y Ref time (momento en que se aplicó por última vez una medición de la fuente horaria)
Se confirma si
El offset del servidor problemático se aleja cientos de ms o más del de los demás, o su Ref time se quedó parado hace tiempo, y los desajustes solo aparecen en los traslados desde o hacia ese servidor
Se descarta si
Si todos los servidores están a pocos ms, apunta al cálculo del tiempo en el juego o a “Error de sincronización del reloj” en el cliente
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Los saltos bruscos hacia delante o hacia atrás del reloj de un solo servidor se tratan en “Salto del reloj del sistema (step de NTP)”, en la capa del SO del servidor.
chrony – Frequently Asked Questionschrony La deriva (drift) del reloj de una computadora normal es menor de 100 ppm, pero en una máquina virtual puede ser mayor; una máquina virtual suspendida y reanudada puede quedar con la hora desfasada y necesitar una corrección por salto (step)
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_REALTIME puede saltar de forma discontinua por cambios manuales o correcciones de NTP; CLOCK_MONOTONIC no se ve afectado por esos saltos
chronyc(1)chrony En chronyc tracking: System time (diferencia entre el reloj NTP y el reloj del sistema), Last offset (offset estimado en la última corrección), Ref time (momento en que se aplicó la última medición de la fuente horaria)
Ver también
Misma capa: L13 Arquitectura y operación de servidores