O que fazer quando o I/O de disco da VPS está muito alto (2026): iowait, iostat, iotop, banco de dados e logs

O primeiro passo é olhar top:

top

Na linha de CPU, olhe %wa. Se %wa fica alto por muito tempo, significa que a CPU passa bastante tempo esperando o I/O de disco ser concluído.

Você também pode usar:

vmstat 1

Foque em:

• wa: proporção de CPU esperando I/O;
• bi / bo: leituras e gravações de dispositivos de bloco;
• r: processos esperando CPU;
• b: sono ininterruptível, comum ao esperar por I/O.

Se wa está muito alto, b também não está baixo e a máquina parece travada, não fique apenas olhando os logs da aplicação.

Instale a ferramenta:

sudo apt install sysstat -y

Ou em sistemas RHEL:

sudo dnf install sysstat -y

Ver métricas estendidas do disco:

iostat -x 1

Foque nestas colunas:

• %util: grau de ocupação do dispositivo;
• await: tempo médio de espera das requisições de I/O;
• r/s, w/s: requisições de leitura/gravação por segundo;
• rkB/s, wkB/s: throughput de leitura/gravação por segundo;
• aqu-sz: comprimento médio da fila.

Julgamento simples:

• Se %util fica próximo de 100% por muito tempo, o disco está muito ocupado;
• Se await aumenta claramente, a espera de I/O ficou mais longa;
• Se aqu-sz fica alto por muito tempo, as requisições estão na fila;
• Se o throughput não é alto mas o await é muito alto, pode ser I/O aleatório, limite de IOPS ou latência do armazenamento subjacente.

Não olhe apenas um valor. Um iowait alto só significa que a CPU está esperando I/O, não prova diretamente que "o disco está com defeito". Combine com iostat e as leituras e gravações em nível de processo.

Instale:

sudo apt install iotop -y

Execute:

sudo iotop -oPa

Significado dos parâmetros:

• -o: mostrar apenas processos que estão gerando I/O;
• -P: agregar por processo em vez de thread;
• -a: mostrar o volume acumulado de leitura e gravação.

Processos que costumam aparecer no topo:

• mysqld / mariadbd / postgres: leituras e gravações do banco de dados;
• dockerd / containerd: logs de contêineres ou camadas de imagem;
• journal / rsyslogd: gravação de logs do sistema;
• backup / tar / gzip / rsync: compressão e sincronização de backup;
• updatedb / apt / dpkg: tarefas de indexação ou instalação;
• Processos de aplicação: gravando logs ou arquivos temporários sem parar.

Se um processo em iotop continua gravando muito, não se apresse em matar o processo; primeiro confirme o que ele está gravando.

iotop é ótimo para ver a situação atual, enquanto pidstat é mais adequado para ver tendências ao longo de um período.

pidstat -d 1

Ver um processo específico:

pidstat -d -p PID 1

Foque em:

• kB_rd/s: leituras por segundo;
• kB_wr/s: gravações por segundo;
• kB_ccwr/s: gravações canceladas.

Se a gravação de uma aplicação continua alta, verifique também seu diretório de logs, diretório de uploads e diretório de cache.

Primeiro veja os diretórios grandes:

sudo du -xh /var/log --max-depth=1 | sort -h

Veja os logs que mudaram rapidamente recentemente:

sudo find /var/log -type f -printf '%s %p\n' | sort -n | tail -n 20

Ver em tempo real se um log está crescendo sem parar:

sudo tail -f /var/log/nginx/error.log

Cenários comuns:

• Nginx registra erros de upstream repetidamente;
• Pilhas de exceção da aplicação inundam a tela;
• Contêineres Docker gravam logs stdout/stderr sem limite;
• fail2ban, falhas de autenticação ou acesso de rastreadores causam explosão de logs;
• O log de depuração foi esquecido ativado.

Se forem logs do Docker, consulte: O que fazer quando o Docker enche o disco da VPS. Aquele artigo trata do uso de disco, enquanto este foca nos travamentos de I/O; os dois problemas costumam aparecer juntos.

Se em iotop aparece MySQL, MariaDB ou PostgreSQL, isso não significa que o banco de dados "tem um problema"; pode ser que o negócio realmente esteja lendo e gravando, ou podem ser consultas lentas, índices ausentes, tabelas temporárias, checkpoints, vacuum ou backups.

Primeiro olhe no nível do sistema:

sudo iotop -oPa
pidstat -d -p $(pidof mysqld) 1
pidstat -d -p $(pidof postgres) 1

Depois olhe os logs do banco de dados:

sudo journalctl -u mysql -n 100 --no-pager
sudo journalctl -u mariadb -n 100 --no-pager
sudo journalctl -u postgresql -n 100 --no-pager

Causas comuns:

• Falta de índices causando muitas leituras aleatórias;
• Consultas que geram grandes tabelas temporárias;
• Tarefas de backup colidindo com o horário de pico do negócio;
• Alta pressão de gravação de binlog / WAL;
• A gravação do banco de dados fica lenta quando o disco está quase cheio;
• Memória insuficiente causando baixa taxa de acerto do cache.

Se não for possível conectar ao banco de dados ou o serviço falhar ao iniciar, consulte os artigos específicos de MySQL, PostgreSQL e Redis, respectivamente; aqui primeiro determinamos se o I/O é causado pelo banco de dados.

VPS com pouca memória encontram facilmente thrashing de swap. Na aparência é I/O de disco alto, mas a causa raiz é memória insuficiente, e o sistema troca páginas de memória para dentro e para fora com frequência.

Verifique:

free -h
swapon --show
vmstat 1

Em vmstat, veja:

• si: swap in;
• so: swap out.

Se si/so permanece diferente de 0 continuamente e %wa está alto ao mesmo tempo, o swap participa do travamento.

Como mitigação temporária, você pode parar serviços desnecessários, reduzir a concorrência e escalonar tarefas. A longo prazo, ainda é preciso otimizar a memória, adicionar cache, fazer upgrade do plano ou separar o banco de dados e a aplicação.

Muitos picos de I/O são criados por nós mesmos.

Por exemplo:

tar -czf backup.tar.gz /var/www /var/lib/mysql
rsync -av /data remote:/backup
mysqldump app > app.sql
docker save image > image.tar

Se essas tarefas coincidem com o horário de pico do negócio, as gravações no banco de dados e a rotação de logs, a VPS trava facilmente.

Diagnostique as tarefas agendadas:

crontab -l
sudo crontab -l
systemctl list-timers --all

Veja os logs recentes:

journalctl --since "2 hours ago" --no-pager

Se for causado por tarefas agendadas, consulte: O que fazer quando as tarefas agendadas da VPS não são executadas; os métodos de diagnóstico de lá também servem para encontrar "quem está gerando I/O periodicamente".

Em cenários Docker, o I/O alto costuma vir de dois lugares:

1. Logs de contêineres gravando sem parar;
2. A camada overlay2 gravando arquivos temporários com frequência.

Primeiro veja o status dos contêineres:

docker ps --size

Veja o tamanho dos logs:

sudo du -xh /var/lib/docker/containers --max-depth=2 | sort -h | tail -n 20

Veja se os logs de um contêiner estão inundando:

docker logs 容器名 --tail 100

Se o negócio permitir, configure rotação de logs para o Docker, por exemplo max-size e max-file em json-file. Não deixe um contêiner anormal arrastar o disco e o I/O do host.

Se você já confirmou:

• Não há processos evidentes de gravação massiva;
• A pressão do banco de dados e dos logs não é alta;
• O swap não tem thrashing evidente;
• As tarefas de backup não estão em execução;
• Mas await fica alto por muito tempo, %util está alto, e o SSH e todas as aplicações travam juntos;
• É mais evidente no horário de pico da noite, ou usuários no mesmo nó também relatam lentidão;

Então pode ser contenção de armazenamento do host, limites de IOPS ou impacto de vizinhos.

Nesse momento, não envie apenas "o disco está lento". Anexe evidências ao ticket do provedor:

date
uptime
vmstat 1 10
iostat -x 1 10
sudo iotop -oPa -b -n 5
free -h
df -h

Se você fizer testes com fio, cuidado para não fazer teste de estresse no disco de produção sem critério durante o horário de pico do negócio. Em uma VPS pequena, o fio pode deixar o negócio ainda mais lento.

Quando encontrar I/O de disco alto ou iowait alto na VPS, verifique nesta ordem:

1. Use top para ver se %wa permanece alto.
2. Use vmstat 1 para ver wa, b, bi/bo e si/so.
3. Use iostat -x 1 para ver %util, await e aqu-sz.
4. Use iotop -oPa para encontrar os processos que estão lendo e gravando.
5. Use pidstat -d 1 para ver a tendência de leitura e gravação dos processos.
6. Use du -xh /var/log para verificar se os logs estão explodindo.
7. Verifique o banco de dados, Docker, backups, compressão e tarefas de sincronização.
8. Use free -h, swapon --show e vmstat para determinar thrashing de swap.
9. Escalone tarefas pesadas, limite logs e otimize consultas e cache do banco de dados.
10. Quando não houver causa local, leve evidências de iostat/vmstat/iotop ao provedor.

Quando o I/O de disco da VPS está alto, não olhe apenas a CPU e não reinicie diretamente. Primeiro use top e vmstat para confirmar se é iowait, depois use iostat -x para julgar a latência e as filas do disco, e por fim use iotop e pidstat para encontrar o processo específico.

A maioria dos problemas acaba sendo explosão de logs, leituras e gravações aleatórias no banco de dados, logs do Docker, thrashing de swap, colisão de tarefas de backup ou contenção de armazenamento do host. Se conseguir localizar o processo, corrija primeiro a máquina local; se não conseguir localizar uma causa local, então leve métricas completas ao provedor, para que o ticket tenha força.