Servidor lento? Como achar gargalos de disco NVMe no Linux

Por que o armazenamento ultrarrápido ainda apresenta lentidão

Quando migramos discos rígidos tradicionais para unidades de estado sólido baseadas no barramento NVMe, esperamos um salto gigante de velocidade. Na prática, esses dispositivos conseguem ler e gravar dados em velocidades impressionantes, medindo centenas de milhares de operações por segundo. No entanto, em servidores de alta carga, como bancos de dados transacionais ou plataformas de streaming, o sistema operacional pode enfrentar gargalos invisíveis. Na hora em que a fila de requisições acumula, o gargalo deixa de ser o hardware bruto e passa a ser a forma como o kernel gerencia o fluxo de dados.

Para entender esse comportamento, pense no NVMe como uma rodovia de dez pistas. Se o tráfego for moderado, os carros voam. Mas se houver um pedágio mal configurado na entrada, haverá congestionamento mesmo com a pista livre. No Linux, esse pedágio é gerido pelas filas de E/S. Quando os aplicativos exigem mais do que o controlador consegue despachar, a latência dispara. Assim como investigamos quedas em redes monitoradas com eBPF, precisamos de ferramentas precisas para abrir o capô do armazenamento e descobrir onde o tráfego está travando de verdade.

Medindo a pulsação do sistema com o utilitário iostat

O primeiro passo em qualquer investigação de performance de armazenamento é observar o comportamento global do sistema. O utilitário iostat, presente na maioria das distribuições Linux, mostra estatísticas cruciais sobre a utilização da CPU e o volume de transferência de dados por dispositivo. Quando executamos o comando em tempo de execução, precisamos olhar atentamente para métricas como o tempo de espera nas filas e o percentual de ocupação do disco.

Para monitorar um disco NVMe específico a cada dois segundos, executamos o comando abaixo no terminal do servidor:

iostat -xz 2

Na prática, o parâmetro -x revela dados avançados, incluindo o tempo médio que cada requisição leva para ser atendida, conhecido como svctm, e o tempo total de espera na fila, chamado de await. Se o valor do await estiver muito acima do svctm, isso significa que seus dados estão ficando presos em uma fila de espera interna do sistema operacional. Esse é o primeiro indício claro de que a aplicação está enviando mais comandos do que o controlador NVMe consegue processar simultaneamente.

Simulando cargas extremas e medindo limites com o fio

Muitas vezes, o gargalo só aparece quando o servidor atinge o limite máximo de esforço. Para diagnosticar o comportamento do disco antes que o problema afete os usuários reais, utilizamos o fio, considerado o canivete suiço dos testes de estresse de armazenamento. Com ele, conseguimos simular leituras e gravações simultâneas em blocos de diferentes tamanhos, imitando exatamente o comportamento de um banco de dados pesado.

Para rodar um teste rápido de gravação randômica que estressa o subsistema NVMe, utilizamos o seguinte comando:

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

Neste exemplo prático, configuramos quatro tarefas paralelas executando gravações aleatórias em blocos de 4 kilobytes, mantendo uma profundidade de fila de 64 operações simultâneas. Observar o comportamento da latência durante esse teste ajuda a entender se o dispositivo sofre degradação de performance sob aquecimento ou se o controlador atinge o limite de canais internos de comunicação.

Rastreando a jornada dos dados com o blktrace

Quando as métricas gerais e os testes sintéticos não revelam a causa raiz da lentidão, precisamos de uma ferramenta de raio-X. O blktrace é um utilitário avançado que captura eventos em nível de bloco do kernel, registrando o exato microssegundo em que uma requisição entra na fila, quando é enviada para o driver e quando o hardware confirma a conclusão.

Para iniciar uma captura detalhada em um dispositivo de bloco e depois gerar um resumo legível, executamos os comandos na sequência:

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

Na prática, essa ferramenta gera um volume massivo de dados que mapeia o ciclo de vida completo de cada operação de leitura ou escrita. Analisando a saída, conseguimos identificar se o atraso ocorre na camada do sistema de arquivos, no agendador de E/S do kernel ou diretamente na controladora física do SSD. Esse nível de visibilidade é indispensável para diagnosticar problemas complexos em ambientes de missão crítica.

Considerações finais sobre o diagnóstico de armazenamento

Identificar gargalos em discos NVMe exige ir além dos números superficiais de velocidade máxima divulgados pelos fabricantes. Ao combinar a visão panorâmica do iostat, a capacidade de estresse controlado do fio e a precisão cirúrgica do blktrace, engenheiros conseguem isolar a origem exata da latência oculta. Compreender essas métricas garante que o investimento em hardware de altíssima performance realmente se traduza em uma experiência rápida e estável para os usuários finais da aplicação.