Servidor lento, acesso remoto engasgando… um simples ls demora segundos pra rodar. Abrir um log? Esquece. Dá tempo de passar um café, tomar o café, e o cursor ainda tá lá, piscando, zombando da sua cara.
Você corre pro painel do servidor (ou pro rack, se for das antigas) e vê o LED do disco rígido aceso fixo, parecendo a luz de Power, só que vermelha e desesperada. Ou, se você está na nuvem, vê o gráfico de IO Wait da CPU batendo no teto.
E pensa: “Deu ruim. O que tá matando meu disco?”
Antigamente, a gente tinha que adivinhar. Hoje, a gente usa o iotop.
O Problema: Quem tá comendo o disco?
Em situações de I/O intenso, a pergunta de um milhão de dólares é: qual processo está fazendo isso?
Ferramentas como o iostat ou o vmstat (colunas bi e bo) até mostram que o disco está sendo massacrado, mas elas não te dizem quem é o culpado. Elas te dão o sintoma, não o nome do meliante.
É aí que entra o iotop. Ele é tipo um top, só que pra disco. Ele mostra em tempo real qual processo está lendo ou escrevendo, quanto está consumindo, e te dá o PID pra você tomar as providências cabíveis (leia-se: kill -9 ou otimizar a aplicação).
Instalação (sem compilar kernel, por favor)
Se você achou esse artigo antigo de 2009 falando pra compilar kernel e instalar Python na mão… esquece. A vida em 2026 é mais fácil.
Hoje em dia, o suporte a TaskStats já vem ativado no kernel de qualquer distribuição decente. Você só precisa instalar o pacote.
Debian / Ubuntu / Mint
sudo apt update
sudo apt install iotop
RHEL / CentOS / Fedora / AlmaLinux
sudo dnf install iotop
Arch Linux
sudo pacman -S iotop
Algumas distros modernas já trazem o
iotop-c, que é uma versão reescrita em C, muito mais leve que a original em Python. Se o seu gerenciador de pacotes tiver essa opção, prefira ela!
Como usar (sem segredo)
O comando precisa de root, porque ele precisa ler estruturas do kernel que usuário comum não mexe.
sudo iotop
Mas o iotop puro mostra todos os processos, inclusive os que não estão fazendo nada de disco. Isso polui a tela. O “pulo do gato” é usar a flag -o (only), que mostra apenas quem está gerando tráfego de disco agora:
sudo iotop -o
Outras flags úteis
-o(Only): Mostra só quem está usando disco. Essencial.-P(Processes): Por padrão, oiotopmostra threads. Se você tem um Java ou um MariaDB rodando, vai ver centenas de linhas. Use-Ppara agrupar tudo e ver só os processos principais.-a(Accumulated): Essa é mágica. Em vez de mostrar a velocidade instantânea, ele mostra o acumulado de leitura/escrita desde que você abriu o programa. Ótimo pra pegar aquele script que roda rapidinho, some, e volta a cada 5 segundos.
Entendendo o que você vê
“Cadê as colunas SWAPIN e IO?”
Se você abriu o iotop e só viu as colunas de leitura e escrita, sem SWAPIN e IO… calma. Provavelmente você vai ver um aviso assim:
Isso acontece porque o kernel tem uma feature chamada task_delayacct que precisa estar ativa pra coletar essas métricas de delay. É ela que permite o kernel rastrear quanto tempo cada processo passa esperando por I/O.
A boa notícia? Dá pra ativar na hora, sem reiniciar nada. Só apertar Ctrl+T dentro do iotop que ele faz o toggle pra você. Pronto, as colunas mágicas aparecem.
Porque coletar essas métricas tem um custo (pequeno, mas existe). Algumas distros preferem deixar desligado por padrão e você ativa quando precisa. Faz sentido.
As colunas principais
Agora sim, com tudo ativado, você vai ver quatro colunas que importam:
DISK READ e DISK WRITE são as mais óbvias — mostram a velocidade de leitura e escrita em bytes por segundo. Aquele backup rodando? Vai aparecer com uns 200 MB/s de WRITE. Fácil de entender.
Já SWAPIN e IO são percentuais de tempo de espera. E é aqui que mora o diagnóstico de verdade:
- SWAPIN alto? Seu problema não é disco, é RAM. O processo tá esperando memória voltar do swap.
- IO alto? Bingo. O processo tá travado esperando o disco responder.
Se você vê um processo com IO perto de 99%, achou o culpado. Ele tá monopolizando o disco e travando todo o resto.
“Mas DK, eu uso SSD NVMe, isso ainda importa?”
Importa mais ainda.
Sim, SSDs são rápidos. Mas na nuvem (AWS, Azure, DigitalOcean), o disco tem limites de IOPS (operações por segundo). Se você estoura esse limite, a nuvem “corta” seu desempenho. O disco fica artificialmente lento.
O iotop te ajuda a ver se você está batendo nesse teto. Às vezes, um log de erro mal configurado escrevendo 1GB de texto inútil por minuto é o suficiente pra travar uma instância pequena, mesmo com SSD.
Resumo da Ópera
Não saia resetando servidor lento igual um desesperado. Instale o iotop, rode um sudo iotop -oP, ache o processo culpado e resolva o problema na raiz.
Seu servidor agradece, e seu café também (porque agora você vai tomar ele com calma, e não estressado).
Deixe um comentário