iostat e iotop: diagnosticar gargalos de armazenamento no Linux

Quando um servidor Linux parece lento, o armazenamento é um dos primeiros locais a verificar. O iostat mostra se o disco está sobrecarregado; o iotop mostra qual o processo que está a causar a carga. Usados em conjunto, respondem às duas perguntas que importam: será que o disco é realmente o gargalo e, se for, o que o está a sobrecarregar? Este artigo aborda a instalação, como interpretar a saída (incluindo onde se encontra a métrica do iostat %util no hardware moderno) e um fluxo de trabalho para passar do sintoma à correção.

Instalar o iostat e o iotop

O iostat vem com o pacote sysstat; o iotop é fornecido separadamente. Instale ambos:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

No Ubuntu, o sysstat vem desativado. Para recolher dados em segundo plano para análise posterior com sar, edite /etc/default/sysstat, defina ENABLED="true"e reinicie o serviço:

sudo systemctl restart sysstat

O iotop deve ser executado como root. No RHEL 9 e versões mais recentes, a contagem de atrasos está desativada por predefinição, o que deixa o IO e SWAPIN vazias. Ative-a com:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Adicione kernel.task_delayacct = 1 a /etc/sysctl.conf para que a alteração persista após reinicializações.

Ler a saída do iostat

Execute o iostat com estatísticas alargadas e ignore a primeira amostra, que apenas mostra médias desde o arranque:

iostat -xz 2

A -x sinalizador adiciona estatísticas estendidas, -z oculta dispositivos inativos e a 2 atualiza a cada dois segundos. As colunas que importam:

• await: tempo médio em milissegundos para a conclusão de uma solicitação de E/S, incluindo o tempo de fila. O número mais importante quando os utilizadores se queixam de lentidão.
• r/s e w/s: IOPS de leitura e gravação. Combinado com rkB/s e wkB/s estes, indicam se a sua carga de trabalho é aleatória (IOPS elevadas, baixo débito) ou sequencial (IOPS baixas, alto débito).
• aqu-sz: profundidade média da fila. Para HDDs, qualquer valor sustentado acima de 1 significa que o disco não consegue acompanhar.
• %util: percentagem de tempo em que o dispositivo teve pelo menos uma E/S em andamento. Útil em HDDs, enganador em NVMe (ver abaixo).

Uma referência rápida aos limites:

Onde %util se situa

%util é a métrica que a maioria das pessoas procura em primeiro lugar, e no NVMe é ativamente enganadora. O kernel conta %util como «qualquer E/S em curso a qualquer momento», o que é adequado para um disco rotativo que processa um pedido de cada vez, mas não faz sentido para dispositivos NVMe que tratam milhares de pedidos em paralelo através de filas de hardware. Uma unidade NVMe pode ficar a 100% %util enquanto opera a 5% da sua capacidade real.

No NVMe, confie r_await, w_awaite aqu-sz em vez disso. Se r_await permanecer abaixo de 1 ms e a profundidade da fila estiver confortavelmente abaixo da profundidade da fila de hardware do dispositivo (frequentemente 1024 ou superior), a unidade não está realmente saturada, independentemente do que %util diga.

Para uma visualização rápida do NVMe em MB/s em vez de kB/s:

iostat -xm 1

Para uma recolha a longo prazo, pode correlacionar com os registos da aplicação mais tarde:

iostat -x -t 5 720 > /var/log/iostat.log

Isso recolhe amostras a cada 5 segundos durante uma hora. sar do mesmo pacote sysstat fornece-lhe os dados equivalentes com armazenamento histórico persistente e é a melhor escolha para monitorização contínua.

Confirmar com o iowait da CPU

Se o iostat mostrar sobrecarga de armazenamento, verifique também a %iowait coluna no resumo da CPU na parte superior da mesma saída. Valores sustentados %iowait acima de 15-20%, juntamente com um valor elevado await confirma que o estrangulamento é o armazenamento. Se %iowait for elevado, mas await parecer normal, execute vmstat 1 e verifique o si e so . Uma atividade de swap diferente de zero significa que está com limitações de memória e que o tráfego do disco é de paginação, não de E/S da aplicação.

Ler a saída do iotop

Assim que o iostat confirmar um estrangulamento de armazenamento, o iotop indica-lhe qual o processo responsável. Comece com:

sudo iotop -o

A -o oculta os processos inativos, deixando apenas aqueles que estão ativamente a realizar E/S. As colunas a observar:

• DISK READ / DISK WRITE: débito em tempo real por processo. Identifica os processos que mais pesam.
• IO: percentagem de tempo em que o processo fica bloqueado na E/S. Um processo a escrever apenas 50 kB/s pode apresentar 99% de IO se estiver a fazer pequenas chamadas síncronas fsync() . Esta coluna é mais importante do que a taxa de transferência bruta.
• SWAPIN: percentagem de tempo à espera de páginas de swap. Um valor diferente de zero aqui significa que o sistema está a fazer paginação e que o seu «problema de armazenamento» é, na verdade, um problema de memória.

Para aplicações multithread (MySQL, PostgreSQL, cargas de trabalho Java), agregue os threads de volta aos processos com -Pe some -a para acumular os totais desde que o iotop foi iniciado:

sudo iotop -oPa

A -a bandeira é o truque para detetar cargas de trabalho intermitentes, como tarefas de backup que só correm durante alguns segundos de cada vez e que, de outra forma, seriam difíceis de identificar numa visualização em tempo real.

Para registo automático durante janelas noturnas, quando ninguém está a observar:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Isso grava um instantâneo não interativo a cada 10 segundos. Combine-o com carimbos de data/hora das suas tarefas de backup ou cron para identificar o culpado após o facto.

Um fluxo de trabalho de diagnóstico

A maioria das investigações de E/S de disco segue o mesmo caminho:

1. iostat -xz 2 confirmar se o disco é realmente o gargalo. Verifique await, aqu-sze %iowait. Se estes estiverem normais, o problema não é o armazenamento e deve procurar noutro local completamente diferente.
2. iotop -oPa para encontrar o processo que está a causar a carga. Preste mais atenção à coluna de E/S do que à coluna de débito. Os piores culpados são frequentemente programas que fazem muitas pequenas gravações síncronas, e não aqueles que movimentam mais bytes.
3. lsof -p <pid> para ver quais os ficheiros que esse processo está a afetar. Isto geralmente identifica o tipo de carga de trabalho imediatamente: um registo de gravação antecipada da base de dados, um ficheiro de registo da aplicação, um ponto de montagem de cópia de segurança, um ficheiro temporário.

Dois padrões que vale a pena conhecer.

Se vir threads do kernel como jbd2/... (ext4 journal) ou txg_sync (ZFS) no topo dos escritores do iotop, estas estão a responder a gravações de outros processos, não a iniciá-las. O processo do espaço do utilizador que está a gerar o tráfego do diário é a causa real; continue a investigar.

Num VPS, um await com baixo %util é o clássico sinal de «vizinho barulhento». Outro utilizador está a monopolizar o armazenamento partilhado e a sua E/S está a ficar em fila no lado do hipervisor, não no seu disco virtual. Pode confirmar, mas não resolver isto a partir do interior do convidado; a solução é ou escalar para o fornecedor ou mudar para um servidor com armazenamento isolado.

Resolver gargalos comuns de E/S

Assim que souber o que está a afetar o disco, as soluções são geralmente simples.

Retire a prioridade das E/S não críticas. ionice coloca um processo na classe de agendamento inativo, onde este só utiliza largura de banda do disco quando nada mais a necessita:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

A primeira forma altera um processo em execução; a segunda inicia um novo já na classe de inatividade. No iotop, pode alterar a prioridade de um processo em execução de forma interativa premindo i.

Mova cargas de trabalho intensas para armazenamento mais rápido. Se o iostat mostrar um disco SATA sobrecarregado por gravações na base de dados e houver um NVMe ocioso na mesma máquina, realoque o diretório de dados da base de dados. A diferença de ordem de magnitude em IOPS torna esta a correção de maior impacto disponível.

Defina o agendador de E/S correto. Os kernels modernos têm predefinições razoáveis, mas vale a pena verificar. Para NVMe e SSDs, defina o agendador para none. O dispositivo gere as filas no hardware melhor do que o kernel:

echo none > /sys/block/nvme0n1/queue/scheduler

Para HDDs que lidam com cargas de trabalho mistas, mq-deadline é a escolha habitual.

Monte com noatime. Por predefinição, cada leitura atualiza o carimbo de data/hora do último acesso ao ficheiro, gerando uma gravação por cada leitura. Em sistemas de ficheiros com muitas leituras, isto é E/S desnecessária. Adicione noatime às opções de montagem em /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Ajuste o writeback para gravações em rajadas. Em servidores com bastante RAM, os limites padrão de páginas sujas permitem que o cache de páginas acumule gigabytes de dados não gravados, para depois descarregá-los de uma só vez. Reduza os limites em /etc/sysctl.conf para suavizar isto:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

O disco em si geralmente não é o problema. Quando o iostat mostra IOPS elevadas e baixo rendimento, a carga de trabalho está a realizar E/S aleatórias em dados que poderiam ser sequenciais, ou a executar muitas pequenas gravações que poderiam ser agrupadas. Analise a aplicação antes de culpar o hardware.

Se estiver a executar cargas de trabalho com grande volume de armazenamento num servidor onde a rede pode ultrapassar o disco, os servidores dedicados com suporte NVMe da FDC oferecem-lhe a margem necessária para aplicar o ajuste acima de forma produtiva.