O servidor está lento: por onde começar

Um procedimento de diagnóstico de cinco minutos: CPU, memória, disco, rede — como usar alguns comandos para identificar o que exatamente está travando e o que fazer depois.

Atualizado em 23 de agosto de 2026

“Está tudo lento” não é um diagnóstico. Existem apenas quatro gargalos: CPU, memória, disco e rede. Abaixo está uma ordem de verificação que aponta para um deles em cinco minutos.

Passo 1: a visão geral

uptime
free -h
df -h

Três comandos já eliminam metade das opções. Se a carga média estiver visivelmente maior que o número de núcleos do seu tier, há uma fila — veja Load average. available próximo de zero significa memória. Se a partição estiver 100% cheia, não procure mais — leia Sem espaço.

Passo 2: qual é exatamente o gargalo

vmstat 2 5

Observe as colunas de média, todas exceto a primeira linha:

us e sy altos, r grande — limitado por CPU;
wa alto, b grande — limitado por disco;
si e so diferentes de zero — está havendo swapping, o que significa que a memória está acabando;
st alto — tempo consumido pelo hypervisor, é uma causa externa, contate o suporte.

Passo 3: encontre o culpado

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
iotop -boPan 3 | head -20        # apt install iotop
ss -tn state established | wc -l

O quadro ao vivo é mais fácil de ler no htop ou btop. Fique atento a processos no estado D — eles estão esperando pelo disco e elevando a carga.

Se o culpado for a sua aplicação, a próxima pergunta é sobre ela: consultas lentas ao banco de dados, um índice ausente, workers demais, um loop infinito após um deploy. Correlacione o momento em que a lentidão começou com o log:

journalctl --since "1 hour ago" -p warning

Passo 4: verifique o histórico

Abra “Overview” no painel /hosting/vds/m/<id> e observe os gráficos do último dia e da última semana. Três padrões típicos:

um degrau para cima em um momento específico — algo mudou: um deploy, uma atualização, uma nova tarefa cron;
um pico regular em um horário fixo — uma tarefa em segundo plano; mova-a para a noite ou limite-a com nice e ionice;
um platô constante por semanas — você simplesmente superou o seu tier.

O que fazer com o resultado

Gargalo	Ação rápida	Solução de longo prazo
CPU	encontre e pare o processo extra	um tier com mais núcleos
Memória	limite workers e buffers do banco de dados, adicione swap	um tier com mais memória
Disco	limite backups com `ionice`, reduza os logs	um tier superior: o platô cresce com o número de núcleos
Rede	limite downloads em segundo plano com `--bwlimit`	investigue a origem do tráfego

O platô do disco é calculado assim: 60 MB/s de escritas por núcleo, não inferior a 60 e não superior a 400, com leituras duas vezes maiores. Se você está consistentemente no platô, o disco não vai ficar mais rápido sem subir de tier — veja Benchmark.

Erros comuns

Reiniciar a máquina imediatamente. Um reboot apaga o quadro, e em uma hora tudo vai se repetir. Colete os números primeiro.
Confiar em um único frame. Um pico no momento em que você abre o htop não significa nada — observe por um minuto.
Tratar memória cheia como problema. Olhe available e o swap, não free.
Mudar de tier sem entender o problema. Um vazamento de memória ou um script em loop vai junto com você para o novo tier. O downgrade de volta não é suportado.

Se CPU, memória e disco estão tranquilos mas a aplicação está lenta, o gargalo está fora da máquina: uma API externa lenta, DNS ou a rede do cliente. Verifique com curl -w '%{time_total}\n' -o /dev/null -s para o endereço que você precisa.