ID da causa dk-fsync · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de banco de dados (Equipe de infraestrutura)
Pedir que os dados sejam gravados “de verdade” no disco leva de 0,1 ms a dezenas de ms por chamada, conforme o disco, e, quando os pedidos se acumulam, a fila cresce.
Por quê Salvamentos periódicos e ondas de logout concentram pedidos de gravação garantida → Efeito A fila do disco cresce → Na tela Lag a cada salvamento, atraso no logout e na troca de canal
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Agrupar salvamentos e gravar de uma vez (vários salvamentos com um só fsync), espalhar os horários de salvamento.
O que fazer (Equipe de infraestrutura)
Servidores/SO: usar SSD para servidores com proteção contra queda de energia, monitorar o tamanho da fila do disco e a latência do fsync. Servidores de BD: se os salvamentos vão para o BD, colocar também o disco de log do BD no mesmo tipo de SSD, monitorar a latência de commit.
Números de referência
O tempo por chamada varia conforme o hardware, mas fica mais ou menos em 0,1 ms em SSD para servidores (com proteção contra queda de energia), de 1 a alguns ms em SSD comum, 1–2 ms em disco na nuvem e 10 ms ou mais em HDD. Se uma thread espera uma chamada de cada vez, o HDD não consegue fazer nem 100 em 1 segundo.
No gráfico
Picos em intervalos regulares · Tamanho da fila do disco, latência de flush e de escrita
Onde olhar
Sobrepor aos horários de salvamento periódico e de logout o f/s e o f_await do iostat -x 1 (número de flushes atendidos pelo disco e tempo gasto), além de w/s, aqu-sz e w_await. Versões antigas do sysstat mostram aqu-sz como avgqu-sz. Em disco na nuvem, ver VolumeQueueLength e VolumeAvgWriteLatency do EBS
Confirma se
A cada salvamento e onda de logouts, o número de flushes e o tamanho da fila disparam juntos, e w_await e f_await ficam várias vezes acima do normal. Nesses momentos, o salvamento e a troca de canal atrasam
Descarta se
A fila dispara em horários sem relação com salvamentos e logouts: backup e compressão (dk-backup) ou limite de IOPS (dk-iops). Número de flushes igual, mas tudo mais lento: mais provável, esgotamento dos créditos de burst (dk-burst)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
fsync(2) — Linux manual pageLinux man-pages O fsync esvazia até o cache do disco e bloqueia até o dispositivo confirmar a conclusão
Reliability (PostgreSQL Documentation)PostgreSQL Discos SATA comuns e muitos SSDs têm cache de escrita que se perde numa queda de energia; para gravação garantida, é preciso cache com bateria ou proteção contra queda de energia
Amazon EBS General Purpose SSD volumesAWS Latência de milissegundos de um dígito no disco padrão da nuvem (gp3); no io2 Block Express, média abaixo de 500 µs para I/O de 16 KiB
iostat(1) — Linux manual pagesysstat -x: f/s e f_await (número de requisições de flush atendidas pelo disco e tempo médio), w/s, w_await, aqu-sz (antigo avgqu-sz)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (requisições esperando conclusão), VolumeAvgWriteLatency (latência média de escrita em 1 minuto, instâncias Nitro)