Disco NVMe lento? Como achar gargalos de I/O e IOPS no Linux

Por que o armazenamento NVMe ainda pode gargalar

As unidades de armazenamento modernas baseadas no protocolo NVMe revolucionaram a computação moderna ao eliminar os gargalos mecânicos dos antigos HDs e saltar sobre o barramento SATA tradicional. Na prática, isso significa que nossos servidores agora conseguem processar centenas de milhares de operações por segundo sem suar a camisa. No entanto, mesmo com velocidades estratosféricas de leitura e escrita, aplicações de alta demanda ainda sofrem com lentidão inexplicada. Compreender a saúde do subsistema de armazenamento exige ir muito além de olhar o espaço livre em disco.

Quando uma aplicação trava esperando dados chegarem da memória persistente, o problema raramente é falta de capacidade bruta. O verdadeiro vilão costuma ser a latência de I/O, ou seja, o tempo que o sistema leva para atender a uma requisição de leitura ou gravação. Para diagnosticar isso corretamente, precisamos olhar para métricas fundamentais como IOPS (operações de entrada e saída por segundo) e a profundidade da fila de comandos. Antes de culpar o código da aplicação, vale a pena investigar se o gargalo não está no hardware ou na controladora, algo que também exploramos ao ver como identificar lentidão em SSDs NVMe no Linux de forma direta.

Monitorando o pulso do disco com o iostat

A ferramenta mais rápida e acessível para inspecionar a atividade de discos no Linux faz parte do pacote sysstat. O comando iostat exibe estatísticas detalhadas sobre a utilização da CPU e o desempenho das partições de disco e unidades lógicas. Ao executá-lo com parâmetros de intervalo, conseguimos ver o comportamento exato do hardware sob carga. Na prática, ele nos dá uma visão panorâmica de quanto tempo o disco passa ocupado processando requisições e qual o tamanho médio das filas acumuladas.

Para começar a monitorar em tempo real com atualizações a cada dois segundos, basta rodar o comando abaixo no terminal do seu servidor. Observe atentamente a coluna await, que mede o tempo médio em milissegundos que as requisições levam para serem atendidas, incluindo o tempo na fila e o tempo de processamento físico pelo dispositivo.

iostat -xz 2 5

Se os valores de await dispararem enquanto o percentual de utilização (util) bater em cem por cento, você encontrou um claro indicador de saturação. Isso significa que o disco está recebendo mais pedidos do que consegue processar simultaneamente. Vale lembrar que problemas paralelos de temperatura, como discutido ao analisar como monitorar a temperatura do NVMe no Linux via terminal, também reduzem a velocidade para evitar danos térmicos.

Medindo a capacidade real com testes de estresse

Muitas vezes, as especificações técnicas impressas na caixa do SSD NVMe representam cenários ideais que raramente acontecem no mundo real. Para saber se o seu hardware está entregando o que promete ou se sofre de degradação por desgaste, o melhor caminho é realizar testes controlados. O utilitário fio (Flexible I/O Tester) é o padrão da indústria para simular padrões de carga de trabalho altamente complexos, variando desde acessos sequenciais massivos até milhares de leituras aleatórias simultâneas.

O comando abaixo executa um teste rápido de gravação aleatória com blocos de quatro quilobytes, simulando o comportamento típico de um banco de dados relacional movimentando índices pesados. Ele utiliza múltiplos processos para estressar a controladora e medir o comportamento real da latência sob pressão.

fio --name=randwrite-test --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --size=1G --iodepth=64 --runtime=60 --time_based

Analisar o relatório gerado pelo fio exige prestar atenção especial na distribuição da latência, expressa em percentis. Se o percentual de noventa e nove por cento (p99) mostrar tempos de resposta na casa dos centenas de milissegundos, sua aplicação certamente sentirá engasgos perceptíveis para o usuário final, mesmo que a média geral pareça aceitável.

Investigando filas profundas e gargalos no kernel

Quando o iostat aponta gargalos mas os testes sintéticos mostram um disco saudável, o problema pode estar na forma como o sistema operacional gerencia as requisições de E/S. O Linux utiliza camadas de software no kernel para organizar o tráfego antes de entregá-lo fisicamente ao barramento NVMe. Ferramentas como o blktrace permitem rastrear cada evento de I/O em nível de bloco, mapeando exatamente onde o atraso ocorre na pilha de software.

Para capturar eventos de rastreamento em tempo real em uma unidade específica e convertê-los em um formato legível, combinamos o blktrace com o utilitário blkparse. Isso ajuda a identificar se o agendador de E/S do kernel está enfileirando requisições de maneira ineficiente para a topologia do seu hardware.

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

Essa análise minuciosa é indispensável em ambientes de alta densidade de virtualização ou em clusters de banco de dados onde múltiplos processos competem pelos mesmos canais de DMA. Identificar se o gargalo reside na fila do driver ou na própria controladora evita substituições de hardware desnecessárias. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Chip de rede queimado na placa-mãe? Como testar com multímetro.

Considerações finais

Diagnosticar gargalos de I/O em discos NVMe no Linux deixa de ser um mistério quando combinamos observação em tempo real com testes de estresse direcionados. O segredo está em não olhar apenas para a velocidade máxima teórica, mas sim para a consistência da latência e o comportamento das filas de comandos sob estresse operacional. Manter rotinas de monitoramento preventivo garante que sua infraestrutura permaneça resiliente, rápida e pronta para suportar picos de acesso sem degradação imperceptível.