Latência de I/O de disco com iostat -x: r_await, w_await, aqu-sz e por que o %util engana em SSD e RAID

O que é

O iostat -x (sysstat) acrescenta colunas estendidas por dispositivo à visão simples de throughput de leitura e escrita. O manual define os campos mais úteis para analisar latência: r_await e w_await são o tempo médio, em milissegundos, para que as requisições de leitura e de escrita sejam atendidas, incluindo o tempo em fila e o tempo de atendimento; aqu-sz é o tamanho médio da fila de requisições emitidas ao dispositivo; %util é a porcentagem do tempo decorrido durante a qual houve requisições de I/O emitidas ao dispositivo.

Os nomes das colunas dependem da versão do sysstat. Versões mais antigas (por exemplo, o sysstat 10.x no RHEL 7) mostram avgqu-sz, avgrq-sz (em setores) e svctm, um campo em que o próprio manual já recomendava não confiar; as versões atuais os chamam de aqu-sz e areq-sz/rareq-sz/wareq-sz (em kilobytes) e não documentam mais o svctm. Também varia conforme a versão se uma coluna await combinada aparece ao lado de r_await/w_await na saída de -x; por isso, os scripts devem identificar os campos pelo nome no cabeçalho, e não pela posição da coluna.

Por que importa

Separar o await em leitura e escrita é importante porque os dois podem diferir enormemente no mesmo dispositivo — por exemplo, escritas sequenciais mas leituras aleatórias em um disco rotativo — e uma única média combinada esconde isso. O aqu-sz conta as requisições pendentes no dispositivo, incluindo as que estão sendo atendidas. Em um dispositivo que atende uma requisição por vez, um valor persistentemente acima de cerca de um indica que há requisições enfileiradas; SSDs, NVMe e conjuntos RAID atendem muitas requisições em paralelo, então um aqu-sz mais alto neles é normal e só importa quando sobe junto com o await. O %util era um sinal confiável de saturação em um dispositivo capaz de atender apenas uma requisição por vez; o manual afirma claramente que a saturação do dispositivo ocorre quando o valor se aproxima de 100% em dispositivos que atendem requisições em série, mas que, para dispositivos que atendem requisições em paralelo — arrays RAID e SSDs modernos são os exemplos do próprio manual —, esse número não reflete seus limites de desempenho, pois um dispositivo assim pode ficar em 100% (nunca ocioso) mesmo estando bem longe do seu teto real de throughput ou de latência.

Como aplicar

• Leia primeiro r_await/w_await para ver a latência percebida pelo usuário, avaliando-os pela faixa esperada do próprio armazenamento, e não por um número fixo para dispositivos diferentes entre si.
• Observe se o aqu-sz tem tendência de alta ao longo de amostras consecutivas junto com o aumento do await, comparando com o que é normal para aquele dispositivo.
• Em SSD, NVMe e RAID, trate o %util como indicador de atividade, não como porcentagem de saturação; um dispositivo rápido parado em 100% com await baixo não é o gargalo.
• Colete amostras repetidas (iostat -xz 1 10) em vez de uma só; o primeiro relatório cobre o tempo desde o boot, não o intervalo de amostragem (-y o omite).
• Restrinja a análise a um dispositivo (iostat -x <device> 1) assim que surgir um candidato na lista completa.

Armadilhas

• Criar alertas apenas com base em %util em armazenamento moderno e deixar passar um enfileiramento real que o aqu-sz teria mostrado.
• Comparar o await entre dispositivos diferentes (armazenamento em rede, NVMe local, um RAID em meio a uma reconstrução) como se um único limite valesse para todos.
• Esquecer que a primeira linha após iniciar o iostat é uma média desde o boot, não o estado atual.