ID de la causa dk-fsync · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de BD (Equipo de infraestructura)
Pedir que los datos se escriban en disco “con garantía” cuesta, según el disco, de 0.1 ms a decenas de ms por llamada, y si se acumulan las solicitudes, la cola se alarga.
Por qué Los guardados periódicos y las avalanchas de cierres de sesión concentran solicitudes de escritura garantizada → Efecto La cola del disco se alarga → En pantalla Lag en cada guardado, retrasos al cerrar sesión o cambiar de canal
A intervalos regulares, Cuando se junta mucha gente
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura), Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Agrupar los guardados (varios guardados con un solo fsync), repartir los guardados en el tiempo.
Tareas (Equipo de infraestructura)
Servidores/SO: usar SSD para servidores con protección contra cortes de energía, monitorear la longitud de la cola del disco y la latencia de fsync. Servidores de BD: si los guardados van a la BD, poner también el disco de logs de la BD en ese tipo de SSD, monitorear la latencia de commit.
Cifras de referencia
El tiempo por llamada depende del hardware, pero a grandes rasgos: SSD para servidores (con protección contra cortes de energía), 0.1 ms; SSD normal, de 1 a varios ms; disco en la nube, 1–2 ms; HDD, 10 ms o más. Si un solo hilo espera las llamadas de una en una, un HDD no llega ni a 100 por segundo.
En el gráfico
Picos periódicos · Longitud de la cola del disco, latencia de flush y de escritura
Dónde mirar
f/s y f_await de iostat -x 1 (número de flushes que procesó el disco y cuánto tardaron), y w/s, aqu-sz y w_await, superpuestos a la hora de los guardados periódicos y de los cierres de sesión. Las versiones antiguas de sysstat muestran aqu-sz como avgqu-sz. En discos en la nube, VolumeQueueLength y VolumeAvgWriteLatency de EBS
Se confirma si
En cada guardado y en cada avalancha de cierres de sesión, el número de flushes y la longitud de la cola se disparan a la vez, y w_await y f_await multiplican varias veces su valor normal. En esos momentos los guardados y los cambios de canal van lentos
Se descarta si
Si la cola se dispara a horas sin relación con guardados ni cierres de sesión, apunta a copias de seguridad o compresión (dk-backup) o al límite de IOPS (dk-iops). Si el número de flushes no cambia pero todo va más lento, más probable: créditos de ráfaga agotados (dk-burst)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
fsync(2) — Linux manual pageLinux man-pages fsync vacía también la caché del disco y bloquea hasta que el dispositivo confirma que terminó
Reliability (PostgreSQL Documentation)PostgreSQL Los discos SATA normales y muchos SSD tienen una caché de escritura que se pierde con un corte de energía; para tener escritura garantizada hace falta una caché con batería o con protección contra cortes de energía
Amazon EBS General Purpose SSD volumesAWS Latencia del disco estándar de la nube (gp3) de unos pocos milisegundos (menos de 10 ms); io2 Block Express, menos de 500 µs de media con E/S de 16 KiB
iostat(1) — Linux manual pagesysstat -x: f/s y f_await (número de solicitudes de flush que procesó el disco y su tiempo medio), w/s, w_await, aqu-sz (antes llamada avgqu-sz)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (número de solicitudes que esperan a completarse), VolumeAvgWriteLatency (latencia media de escritura por minuto, instancias Nitro)