Servidor lento? Como achar gargalos de disco no Linux com iostat

O que é I/O de armazenamento e por que ele importa

Quando falamos de desempenho de computadores, costumamos lembrar logo da memória RAM e do processador. No entanto, o armazenamento de dados costuma ser o calcanhar de Aquiles de qualquer infraestrutura moderna. O subsistema de I/O, abreviação de Input e Output ou Entrada e Saída, engloba todo o caminho que os dados percorrem desde o momento em que a aplicação solicita uma informação até o instante em que ela é efetivamente gravada ou recuperada do disco rígido ou SSD.

Na prática, isso significa que mesmo um processador extremamente rápido ficará ocioso se os dados não chegarem a ele com velocidade suficiente. Quando as unidades de armazenamento ficam sobrecarregadas, cria-se uma fila invisível de processos aguardando a vez de ler ou escrever. Se você já percebeu seu banco de dados lento sem motivo aparente de CPU, o culpado quase sempre é um gargalo severo no fluxo de armazenamento do sistema operacional.

Compreendendo IOPS, throughput e latência de disco

Para investigar problemas de desempenho com precisão, precisamos dominar três métricas fundamentais: IOPS, throughput e latência. A sigla IOPS significa Input/Output Operations Per Second, ou seja, o número de operações de leitura e escrita que o disco consegue realizar em um único segundo. Essa métrica é vital para cargas de trabalho que lidam com muitos arquivos pequenos e consultas randômicas, como bancos de dados relacionais e sistemas transacionais.

O throughput, por sua vez, mede o volume bruto de dados transferidos por segundo, geralmente expresso em megabytes por fim de segundo. Enquanto os IOPS mostram quantas pequenas tarefas o disco faz, o throughput mostra o peso total da carga. Já a latência é o tempo de espera, medido em milissegundos, entre a solicitação de uma operação de I/O e a sua conclusão efetiva. Uma latência alta indica que o disco está sofrendo para atender aos pedidos, mesmo que os números de IOPS pareçam baixos.

Introdução prática ao comando iostat no Linux

O utilitário iostat faz parte do pacote sysstat nos sistemas operacionais baseados em Linux e é a ferramenta padrão para monitorar estatísticas de CPU e desempenho de dispositivos de armazenamento. Na prática, ele coleta métricas diretamente do núcleo do sistema operacional e exibe um resumo detalhado sobre a utilização do hardware, permitindo que administradores descubram rapidamente qual unidade está estrangulando o fluxo de dados.

Para executar o comando pela primeira vez em seu terminal, geralmente precisamos instalar o pacote caso ele ainda não esteja presente. Em distribuições baseadas em Debian ou Ubuntu, a instalação é feita com o gerenciador de pacotes padrão através de comandos simples e diretos:

sudo apt update && sudo apt install sysstat

Com a ferramenta instalada, você pode digitar apenas iostat no terminal para ver um panorama geral desde a última inicialização do servidor. No entanto, para fins de diagnóstico real, esse retrato histórico costuma ser pouco útil, pois ele nivela os picos de estresse com longos períodos de ociosidade.

Como ler a saída do iostat e identificar gargalos

Para monitorar problemas em tempo real, a abordagem mais eficiente consiste em passar parâmetros que atualizam as estatísticas de forma contínua. Por exemplo, executar o comando informando dois argumentos numéricos faz com que ele exiba novas leituras a cada intervalo de tempo especificado. O comando abaixo atualiza as informações a cada 2 segundos de forma indefinida:

iostat -xz 2

Ao analisar a tabela gerada por esse comando, preste atenção especial em colunas vitais como a r/s (leituras por segundo), w/s (escritas por segundo), await (tempo médio de espera em milissegundos para que as requisições de I/O sejam atendidas) e %util (porcentagem de tempo em que a unidade de disco esteve ocupada processando solicitações).

Quando a coluna %util se aproxima de 100% e o valor de await dispara para centenas de milissegundos, você encontrou um gargalo clássico. Na prática, isso significa que a fila de requisições está crescendo mais rápido do que o disco consegue esvaziá-la, gerando lentidão generalizada em cascata para toda a aplicação hospedada naquele servidor.

Estratégias de mitigação e boas práticas operacionais

Identificar o gargalo com o iostat é apenas o primeiro passo na solução de problemas de infraestrutura. Uma vez descoberto qual disco está estrangulando o sistema, é preciso tomar decisões arquiteturais para aliviar a carga. Entre as abordagens mais comuns estão a migração de discos mecânicos tradicionais (HDD) para unidades de estado sólido (SSD ou NVMe), que oferecem uma quantidade infinitamente maior de IOPS nativos.

Outra estratégia fundamental envolve a otimização de consultas e a implementação de políticas eficientes de cache de aplicação para reduzir a necessidade de acessos físicos constantes ao disco. Além disso, se o espaço em disco for um fator agravante que force paginação excessiva na memória virtual, vale a pena verificar se há acúmulo de arquivos desnecessários usando ferramentas complementares de auditoria e limpeza. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Como testar capacitores eletrolíticos esgotados com capacímetro e Como medir largura de banda e jitter no Linux com o iperf3.

Considerações finais sobre o monitoramento de armazenamento

O domínio de ferramentas de diagnóstico de baixo nível, como o iostat, transforma administradores de sistemas reativos em engenheiros proativos capazes de antecipar falhas. Compreender a relação intrínseca entre IOPS, latência e o comportamento real do hardware permite dimensionar servidores com precisão cirúrgica e evitar desperdício de recursos financeiros.

Monitorar continuamente o subsistema de armazenamento garante que gargalos ocultos sejam identificados e tratados antes de impactarem a experiência dos usuários finais. A observabilidade constante da infraestrutura é o alicerce indispensável para manter aplicações rápidas, estáveis e prontas para crescer.