Limite de IOPS e saturação da fila IOPS limit / queue saturation
ID da causa dk-iops · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando as requisições passam do que o disco consegue atender em 1 segundo, a fila cresce e a latência dispara.
Por quê As requisições de leitura e escrita chegam perto da capacidade do disco → Efeito A fila cresce (em geral, dispara a partir de 90% de utilização) → Na tela Atraso em salvamentos e carregamentos; travamento se a chamada for síncrona
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Agrupar requisições, manter em cache os dados lidos com frequência, usar I/O assíncrono para a thread do jogo não esperar o disco.
O que fazer (Equipe de infraestrutura)
Servidores/SO: usar discos mais rápidos, verificar os limites de largura de banda de disco e de IOPS de cada tipo de instância, criar alertas de utilização e fila do disco, fazer cópias de arquivos grandes em horários tranquilos. Servidores de BD: criar alertas de utilização de IOPS e vazão também nos discos do BD, verificar os limites de disco da configuração da instância do BD.
Números de referência
HDD: cerca de 150 IOPS; SSD SATA: dezenas de milhares; NVMe: centenas de milhares. O disco padrão da nuvem (AWS gp3) entrega 3.000 IOPS e 125 MiB por segundo; o limite de vazão por segundo é separado do de IOPS, e se uma cópia de arquivo grande o esgota, até escritas pequenas ficam esperando na fila.
No gráfico
Achata ao bater no limite · IOPS, tamanho da fila do disco
Onde olhar
Ver r/s e w/s, rkB/s e wkB/s, aqu-sz, r_await e w_await no iostat -x 1. Na nuvem, ver VolumeReadOps, VolumeWriteOps e VolumeQueueLength do EBS e, para saber se o limite foi excedido, VolumeIOPSExceededCheck e VolumeThroughputExceededCheck, além de InstanceEBSIOPSExceededCheck e InstanceEBSThroughputExceededCheck do lado da instância
Confirma se
As requisições por segundo ou a vazão achatam no valor do limite, e aqu-sz e await disparam juntos. Na nuvem, as métricas de limite excedido ficam em 1
Descarta se
%util em 100% com await baixo: ainda pode haver folga. Em SSD e RAID, que atendem requisições em paralelo, %util não indica o limite. await alto sem bater no limite: latência do próprio disco (dk-hdd) ou fsync (dk-fsync)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Na nuvem, além do limite do disco, cada configuração de servidor (tipo de instância) tem limites próprios de largura de banda de disco e de IOPS. Mesmo com um disco caro, se o servidor for pequeno, o gargalo fica no limite da instância.
Fontes
Exos X18 Data SheetSeagate HDD de 7.200 rpm para servidores: 170 IOPS em leitura aleatória de 4K (QD16)
D3-S4520 SSDSolidigm SSD SATA para servidores: até 92K/48K IOPS em leitura/escrita aleatória de 4 KB
Amazon EBS General Purpose SSD volumesAWS Desempenho base do gp3 de 3.000 IOPS e 125 MiB/s, dois limites separados que podem ser aumentados de forma independente
iostat(1) — Linux manual pagesysstat -x: r/s e w/s, rkB/s e wkB/s, aqu-sz (antigo avgqu-sz), r_await e w_await, %util. Em RAID e SSDs modernos, que atendem requisições em paralelo, %util não indica o limite de desempenho
Amazon CloudWatch metrics for Amazon EBSAWS VolumeIOPSExceededCheck e VolumeThroughputExceededCheck: 1 se houve tentativa de passar do limite de IOPS ou de vazão do volume (instâncias Nitro); VolumeQueueLength