Servidor lento? Como achar gargalos de disco com iostat

O que acontece quando o disco vira o gargalo do servidor

Quando a resposta da sua aplicação fica lenta ou o sistema parece travar sem um pico visível de uso de CPU, o culpado quase sempre é o subsistema de armazenamento. O sistema operacional precisa ler e escrever dados em discos mecânicos ou SSDs. Quando esses dispositivos atingem o limite físico de operações por segundo, o processador entra em estado de espera. Em servidores de banco de dados ou sistemas de arquivos de alta carga, entender a causa dessa lentidão é o primeiro passo para restaurar a estabilidade.

Para investigar a comunicação de entrada e saída, conhecida no mercado pela sigla I/O (Input/Output), o Linux oferece o utilitário iostat. Essa ferramenta faz parte do pacote sysstat e detalha como a CPU e os discos de armazenamento lidam com as solicitações dos processos. Se você já lidou com perdas de desempenho parecidas em drivers modernos, como vimos ao identificar gargalos de I/O em discos NVMe no Linux, notará que o iostat é a ferramenta ideal para rastrear esse comportamento em qualquer camada de disco.

Entendendo o impacto do iowait na CPU

Ao executar o comando top ou htop, muitos administradores de sistema notam uma porcentagem alta de uso de CPU sob o rótulo wa ou iowait. O termo iowait representa a porcentagem de tempo que a CPU permaneceu ociosa aguardando a conclusão de operações de gravação ou leitura no disco. Ter iowait alto não significa necessariamente que a CPU está trabalhando demais; pelo contrário, indica que ela está parada esperando por hardware de armazenamento mais lento.

É essencial monitorar o comportamento de processos travados nesse estado. Quando os processos ficam paralisados aguardando a conclusão do disco, eles entram em um estado ininterruptável na tabela do sistema. Para entender a relação entre requisições presas no sistema operacional e falta de recursos, você pode aprender como achar processos zumbis no Linux e liberar a CPU, evitando que o acúmulo de tarefas afete o sistema.

Como instalar e executar o iostat em tempo real

O iostat pode ser instalado facilmente na maioria das distribuições Linux através do pacote sysstat. Para analisar o comportamento real e descartar a média histórica mantida desde a inicialização do sistema, devemos fornecer um intervalo de atualização em segundos para o comando.

1. Instale o utilitário sysstat no seu sistema Debian/Ubuntu ou RHEL/CentOS:

   sudo apt update && sudo apt install sysstat -y

2. Execute o iostat configurado para exibir os dados estendidos e em megabytes por segundo a cada 2 segundos:

   iostat -xz 2

3. Observe as colunas geradas no terminal para identificar o disco específico que apresenta maior tempo de resposta ou acúmulo de solicitações.

Interpretando as métricas essenciais do iostat

A saída da opção estendida (-x) traz diversas colunas que revelam a saúde do armazenamento. A seguir, detalhamos o que cada campo representa na prática:

Device            r/s     w/s     rMB/s     wMB/s   r_await   w_await   aqu-sz  %util  sda             45.00  120.00      1.20     15.40      4.20     35.50     4.80  98.50  nvme0n1          12.00   85.00      0.40      8.10      0.30      0.80     0.10  15.00

A coluna r/s e w/s indicam o número de leituras e escritas completadas por segundo. Já as colunas rMB/s e wMB/s mostram o volume de dados transferido. Contudo, as métricas mais importantes para diagnosticar problemas graves são r_await, w_await, aqu-sz e %util.

A métrica w_await mede o tempo médio, em milissegundos, que as operações de escrita levaram desde a criação na fila do sistema até a confirmação pelo hardware. Se a coluna w_await ou r_await apresentar valores acima de 10 a 20 ms em discos SSD ou acima de 50 ms em HDDs mecânicos, a sua aplicação sentirá latência perceptível. A coluna aqu-sz representa o tamanho médio da fila de requisições pendentes. Valores constantemente superiores a 1 ou 2 indicam que o dispositivo não consegue processar os pedidos na velocidade com que chegam.

A armadilha da coluna %util em unidades modernas

Historicamente, a coluna %util mostrava a porcentagem de tempo em que a unidade de disco esteve ocupada com trabalho. Um valor próximo de 100% em discos mecânicos significava saturação total da cabeça de leitura. No entanto, em SSDs modernos e drives NVMe que suportam múltiplos canais de execução paralela, o campo %util pode chegar a 100% mesmo quando a unidade ainda possui capacidade ociosa de processamento de solicitações.

Portanto, nunca confie exclusivamente no %util. Analise sempre o indicador de latência (r_await e w_await) combinado com o tamanho da fila (aqu-sz). Se a latência continuar baixa e a fila pequena, o sistema continua funcionando perfeitamente mesmo com %util elevado. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como medir ripple em fontes de bancada com osciloscópio.

Diagnóstico e ações para resolver o gargalo de I/O

Ao identificar um disco com w_await elevado e filas acumuladas, a ação corretiva depende da origem da carga. Se o servidor roda bancos de dados como PostgreSQL ou MySQL, é recomendável verificar se consultas sem índice estão forçando leituras sequenciais contínuas no disco ou se escritas de logs de transação estão saturando o dispositivo. Em ambientes virtualizados ou com múltiplos contêineres, verificar o consumo isolado com utilitários como o iotop ajuda a identificar qual processo específico está gerando a carga pesada.

Se a causa for gargalo de hardware inevitável pela demanda da aplicação, estratégias como separação de volumes (colocar logs em um disco e dados em outro), ajuste de parâmetros de cache do kernel (como o vm.dirty_ratio) ou migração para drives de maior IOPS resolverão o problema definitivamente.