Límite de IOPS y saturación de la cola IOPS limit / queue saturation
ID de la causa dk-iops · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de BD (Equipo de infraestructura)
Cuando se supera el número de solicitudes por segundo que el disco puede procesar, la cola se alarga y la latencia se dispara.
Por qué Las solicitudes de lectura y escritura se acercan a la capacidad del disco → Efecto La cola se alarga (normalmente se dispara por encima del 90% de utilización) → En pantalla Guardados y cargas lentos; con llamadas síncronas, congelamiento
Cuando se junta mucha gente, Horas pico de la noche
Responsable
Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Agrupar solicitudes, cachear los datos que se leen a menudo, hacer la E/S asíncrona para que el hilo del juego no espere al disco.
Tareas (Equipo de infraestructura)
Servidores/SO: usar discos más rápidos, revisar los límites de ancho de banda e IOPS de disco de cada tipo de instancia, poner alertas sobre la utilización y la cola del disco, copiar archivos grandes en horas tranquilas. Servidores de BD: poner también alertas sobre la utilización de IOPS y throughput de los discos de la BD, revisar el límite de disco del tamaño de instancia de la BD.
Cifras de referencia
HDD, unas 150 IOPS; SSD SATA, decenas de miles; NVMe, cientos de miles. El disco estándar de la nube (AWS gp3) da 3,000 IOPS y 125 MiB por segundo; si una copia de archivos grandes llena el límite de transferencia por segundo, que es independiente de las IOPS, hasta las escrituras pequeñas se retrasan.
En el gráfico
Topa con el límite · IOPS, longitud de la cola del disco
Dónde mirar
r/s y w/s, rkB/s y wkB/s, aqu-sz, y r_await y w_await de iostat -x 1. En la nube, VolumeReadOps, VolumeWriteOps y VolumeQueueLength de EBS, los indicadores de límite superado VolumeIOPSExceededCheck y VolumeThroughputExceededCheck y, del lado de la instancia, InstanceEBSIOPSExceededCheck e InstanceEBSThroughputExceededCheck
Se confirma si
Las solicitudes por segundo o el volumen de transferencia se quedan planos en el valor del límite, y aqu-sz y await se disparan a la vez. En la nube, las métricas de límite superado valen 1
Se descarta si
Aunque %util esté en 100%, si await es bajo puede que aún quede margen. En SSD y RAID, que procesan solicitudes en paralelo, %util no indica el límite. Si no se llega al límite y solo await es alto, apunta a la latencia del propio disco (dk-hdd) o a fsync (dk-fsync)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
En la nube, además del límite del disco, cada tamaño de servidor (tipo de instancia) tiene su propio límite de ancho de banda e IOPS de disco. Aunque se conecte un disco caro, si el servidor es pequeño, el cuello de botella será el límite de la instancia.
Fuentes
Exos X18 Data SheetSeagate 170 IOPS en lectura aleatoria 4K de un HDD para servidores de 7,200 rpm (QD16)
D3-S4520 SSDSolidigm SSD SATA para servidores: hasta 92K/48K IOPS en lectura/escritura aleatoria de 4 KB
Amazon EBS-optimized instance typesAWS Cada tipo de instancia tiene sus propios límites base y máximos de ancho de banda, throughput e IOPS de EBS
iostat(1) — Linux manual pagesysstat -x: r/s y w/s, rkB/s y wkB/s, aqu-sz (antes llamada avgqu-sz), r_await y w_await, %util. En RAID y SSD modernos, que procesan solicitudes en paralelo, %util no refleja el límite de rendimiento
Amazon CloudWatch metrics for Amazon EBSAWS VolumeIOPSExceededCheck y VolumeThroughputExceededCheck: 1 si se intentó superar el límite de IOPS o de throughput del volumen (instancias Nitro); VolumeQueueLength