ID de la causa dk-sync-log · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si el hilo del juego espera a que el disco termine cada línea de log, cuando el disco está ocupado el juego también se detiene.
Por qué Los logs de combate e intercambios se escriben directamente en archivo desde el hilo del juego → Efecto Si se exige escritura garantizada (fsync) o se llena el búfer de escritura del SO (caché de páginas), cada escritura tarda decenas de ms cuando el disco está ocupado → En pantalla Tirones en los combates que generan muchos logs
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Pasar a logging asíncrono (búfer en memoria + hilo aparte), reducir el volumen de logs, no hacer fsync en el hilo del juego.
Tareas (Equipo de infraestructura)
Ejecutar la rotación y compresión de logs con baja prioridad de E/S, poner los logs en un disco distinto del de los datos, monitorear la latencia de escritura en disco.
En el gráfico
Picos aleatorios · Tiempo de tick del servidor, latencia de escritura en disco
Dónde mirar
w_await y aqu-sz de iostat -x 1 superpuestos al tiempo de tick; buscar con perf trace -p PID --duration 10 las llamadas write y fsync del servidor del juego que tardan más de 10 ms y el hilo que las hace
Se confirma si
En los picos de tick, las llamadas write y fsync del hilo del juego tardan decenas de ms y en ese momento también se dispara la latencia de escritura en disco. A menudo coincide con la rotación o la compresión de logs
Se descarta si
Si el hilo del juego no tiene llamadas al sistema largas y aun así hay picos de tick, apunta a otra causa (GC, locks, tick excedido). Si solo tarda el hilo dedicado a los logs, el juego no se ve afectado
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Normalmente el SO recibe primero las escrituras en memoria (caché de páginas) y las pasa al disco más tarde, así que una línea de log casi siempre termina al instante. Las detenciones aparecen cuando se exige escritura garantizada con fsync, cuando las escrituras pendientes superan el límite y el SO bloquea la llamada de escritura, o cuando se rota o se comprime el archivo de log. Por eso todo va bien la mayor parte del tiempo y los picos solo aparecen cuando el disco está ocupado.
Fuentes
fsync(2) — Linux manual pageLinux man-pages fsync envía los datos modificados hasta el disco (incluida su caché) y bloquea hasta que el dispositivo confirma que terminó
Documentation for /proc/sys/vm/Linux kernel Cuando las escrituras pendientes (dirty) alcanzan dirty_ratio, el propio proceso que escribe tiene que encargarse de escribir en disco
ionice(1) — Linux manual pageutil-linux Las tareas con prioridad de E/S idle solo reciben tiempo de disco cuando ningún otro programa lo está usando
iostat(1) — Linux manual pagesysstat -x: w_await (tiempo medio de servicio de las solicitudes de escritura, incluida la espera en la cola) y aqu-sz (longitud media de la cola, antes llamada avgqu-sz)
perf-trace(1) — Linux manual pageperf -p traza las llamadas al sistema de un proceso en ejecución; --duration muestra solo las que tardan más de los ms indicados