Servidor lento? Como achar gargalos de disco e IOPS no Linux

Por que o seu servidor trava mesmo com pouca CPU?

Quando um servidor de produção começa a responder com lentidão extrema, o primeiro instinto da maioria dos engenheiros é olhar para o consumo de processador e de memória RAM. Na prática, muitas vezes o verdadeiro vilão é o subsistema de armazenamento, que sofre com a saturação de I/O, ou seja, a incapacidade dos discos rígidos ou unidades de estado sólido de acompanhar o volume de requisições de leitura e escrita. Se o processador precisa esperar os dados chegarem do disco para continuar trabalhando, ele fica ocioso aguardando, o que gera uma falsa sensação de folga enquanto o sistema inteiro trava. Esse cenário é extremamente comum em servidores de banco de dados, ambientes virtualizados e aplicações que lidam com grande volume de logs.

Para evitar diagnósticos baseados em achismos, precisamos entender o conceito de IOPS, que significa operações de entrada e saída por segundo. Trata-se da métrica fundamental que mede quantas pequenas leituras ou escritas um disco consegue realizar em um intervalo de tempo. Outro fator crítico é a latência, o tempo que a requisição leva desde o momento em que o sistema operacional a envia até o momento em que o disco confirma a conclusão. Quando a fila de espera cresce e a latência dispara, a aplicação inteira engarrafas. Em situações graves de falta de espaço e desgaste por logs excessivos, administradores costumam recorrer a procedimentos como limpar caches e logs no Linux, mas quando o problema é estrutural de lentidão, precisamos ir muito além da simples limpeza de arquivos temporários.

Monitorando a saúde do disco em tempo real com o iostat

O primeiro passo em qualquer investigação de desempenho de armazenamento no ecossistema Linux é extrair métricas macroscópicas para identificar qual dispositivo físico está sofrendo. O comando iostat, integrante do pacote sysstat, é a ferramenta nativa ideal para essa tarefa inicial. Na prática, ele exibe estatísticas detalhadas sobre a utilização da CPU e a taxa de transferência de dados e requisições de cada partição ou disco conectado ao sistema. Para monitorar o comportamento do hardware continuamente a cada dois segundos, executamos o comando com parâmetros específicos no terminal.

iostat -xz 2 5

Ao analisar a saída desse comando, devemos prestar atenção redobrada em colunas cruciais como await, que indica o tempo médio de espera em milissegundos para que as requisições de I/O fossem atendidas, e %util, que mostra a porcentagem de tempo em que o dispositivo esteve ocupado processando solicitações. Se o parâmetro %util se mantiver próximo de cem por cento por longos períodos e o valor de await disparar para dezenas ou centenas de milissegundos, temos uma evidência clara de saturação de IOPS. Isso significa que o disco chegou ao seu limite físico e não consegue processar o volume atual de trabalho, exigindo otimização de consultas, distribuição de carga ou migração para storages mais rápidos.

Investigando o comportamento em nível de bloco com o blktrace

Quando a visão geral fornecida pelo iostat não é suficiente para isolar a origem de um comportamento errático, precisamos descer o nível de abstração e inspecionar o tráfego diretamente na camada de blocos do kernel do Linux. É exatamente aqui que entra o blktrace, uma ferramenta poderosa capaz de capturar e registrar todas as operações de I/O enviadas aos dispositivos de bloco com precisão de microssegundos. Na prática, ele funciona como uma câmera de alta velocidade apontada para o caminho que os dados percorrem entre o sistema de arquivos e o controlador físico do disco.

Para extrair dados úteis sem sobrecarregar o sistema com logs gigantescos, costumamos combiná-lo com o utilitário blkparse para gerar um resumo legível. O procedimento básico envolve iniciar a captura em segundo plano para um disco específico, como o dispositivo /dev/nvme0n1, reproduzir a carga de trabalho e encerrar a coleta logo em seguida.

blktrace -d /dev/nvme0n1 -o - | blkparse -i -

Essa execução detalha cada requisição de leitura e escrita, mostrando exatamente quando o pedido foi gerado, quando entrou na fila do driver e quando foi concluído pelo hardware. Se observarmos gargalos recorrentes de latência nessa camada, vale a pena investigar se não há problemas de interferência física ou ruídos elétricos na infraestrutura do servidor, um tema crítico que abordamos ao analisar como eliminar EMI no roteamento e aterramento de placas, garantindo a integridade dos sinais elétricos que trafegam pelos barramentos internos e externos.

Simulando cenários de estresse com o fio

Muitas vezes, o maior desafio para um engenheiro de infraestrutura é descobrir o limite de um storage antes que os usuários finais comecem a reclamar de lentidão em ambiente de produção. Para resolver esse dilema de planejamento, utilizamos o fio (Flexible I/O Tester), considerado o canivete suíço dos testes de estresse de armazenamento. Na prática, ele permite simular padrões exatos de acesso ao disco, como leituras sequenciais massivas ou milhares de pequenas escritas aleatórias concorrentes, imitando o comportamento real de bancos de dados relacionais.

Podemos configurar o fio diretamente pela linha de comando para realizar um teste rápido de gravação aleatória com blocos de quatro quilobytes, medindo o desempenho real de IOPS do disco em questão.

fio --name=randwrite-test --filename=/tmp/testfile --size=4G --bs=4k --iodepth=64 --rw=randwrite --direct=1 --ramp_time=2

O parâmetro direct=1 é fundamental porque desativa o cache de leitura e escrita da memória RAM do sistema operacional, forçando a aplicação a interagir diretamente com o disco físico e revelando a verdadeira capacidade do hardware. Ao analisar os resultados do fio, conseguimos estimar com precisão se a nossa infraestrutura atual suportará picos sazonais de acesso ou se precisamos redimensionar o armazenamento antes do próximo grande evento de tráfego.

Considerações finais sobre diagnóstico de armazenamento

O rastreamento eficiente de gargalos de I/O e latência de disco exige uma abordagem metodológica que vai desde a observação macroscópica até a análise microscópica do tráfego no kernel. Ferramentas como iostat, blktrace e fio formam um trio indispensável no arsenal de qualquer engenheiro de confiabilidade de sistemas, permitindo transformar suspeitas subjetivas em diagnósticos técnicos precisos e acionáveis. Compreender o comportamento do subsistema de armazenamento evita investimentos desnecessários em hardware e garante a estabilidade operacional dos serviços críticos que sustentam a empresa.

Em última análise, manter o monitoramento proativo e realizar testes de carga periódicos impede que falhas silenciosas de latência surpreendam a equipe de engenharia em momentos críticos. Ao dominar essas ferramentas nativas do Linux, você ganha autonomia total para identificar a raiz de qualquer lentidão, otimizar fluxos de dados e assegurar que a infraestrutura tecnológica opere sempre em seu potencial máximo de desempenho e confiabilidade.