VPS lenta: como diagnosticar e resolver

Quando a VPS fica lenta, o gargalo é sempre um dos quatro recursos: CPU saturada, RAM no limite (com swap pesado), I/O de disco travando processos ou rede com latência. A ordem de diagnóstico importa, confirme CPU primeiro, depois memória, depois disco, depois rede. Cada um tem sinais distintos nos comandos de monitoramento.

Passo 1: verificar CPU e Load Average

CPU em 100% é o sinal mais visível. Load Average alto com CPU baixa indica I/O wait:

bash
# Snapshot rápido: CPU, load average, processos
top -bn1 | head -20

# Alternativa com mais detalhes
htop

# Load average: 3 valores (1min, 5min, 15min)
# Em VPS de 2 vCPUs: load > 4 por mais de 5min = saturação
uptime

# Qual processo está consumindo CPU
ps aux --sort=-%cpu | head -10

# Consumo de CPU ao longo do tempo (1 amostra por segundo, 10x)
pidstat -u 1 10 | head -30

# Percentual de I/O wait (tempo que a CPU espera disco)
iostat -x 1 5 | grep -E "Device|avg-cpu"
# %iowait acima de 30% = gargalo de disco, não CPU

Passo 2: verificar memória e swap

RAM no limite força o kernel a usar swap, que é muito mais lento que a RAM:

bash
# Ver memória disponível e uso de swap
free -h

# Swap being heavily used = RAM insuficiente
# "available" muito baixo = pressão de memória real

# Processos que mais consomem RAM
ps aux --sort=-%mem | head -10

# Verificar se OOM killer matou processos recentemente
sudo dmesg | grep -i "oom|killed" | tail -20
sudo journalctl -k | grep -i "oom|killed" | tail -20

# Ver se há memory leaks (processo crescendo continuamente)
watch -n 5 'ps aux --sort=-%mem | head -5'

# Uso de memória por container Docker
docker stats --no-stream --format "table {{.Name}}	{{.MemUsage}}	{{.MemPerc}}"

Passo 3: verificar I/O de disco

Disco lento é silencioso, processos ficam em "D" state (uninterruptible sleep) esperando leitura/escrita:

bash
# Ver processos em D state (esperando I/O)
ps aux | awk '$8 == "D" {print}'

# I/O detalhado por disco
iostat -xz 1 5

# O que ler no iostat:
# %util > 80% = disco saturado
# await > 20ms = latência alta de I/O
# r/s e w/s = operações de leitura e escrita por segundo

# Quais processos fazem mais I/O (requer iotop)
sudo apt install -y iotop
sudo iotop -o   # mostra apenas processos com I/O ativo

# I/O por container Docker
docker stats --no-stream --format "table {{.Name}}	{{.BlockIO}}"

Passo 4: verificar rede e latência

Latência de rede afeta apps que fazem muitas chamadas externas (APIs, banco remoto, webhooks):

bash
# Uso de rede por interface
nload eth0      # gráfico em tempo real (apt install nload)
iftop -i eth0   # por conexão (apt install iftop)

# Conexões de rede ativas
ss -tunap | head -20

# Conexões por estado
ss -s

# Testar latência para serviços externos
ping -c 5 8.8.8.8          # latência para internet
ping -c 5 IP_DO_BANCO       # latência para banco remoto

# Verificar se há muitas conexões em TIME_WAIT (normal, mas pode indicar problema)
ss -s | grep TIME-WAIT

# Velocidade de upload/download (benchmark rápido)
curl -o /dev/null https://speed.cloudflare.com/__down?bytes=100000000

Diagnóstico de processo malicioso ou cryptominer

VPS lenta sem causa aparente pode indicar processo malicioso (cryptominer) rodando em background:

bash
# Verificar processos com nome suspeito ou consumo alto de CPU sem razão
ps aux --sort=-%cpu | head -20

# Processos com conexões de rede suspeitas (portas não reconhecidas)
ss -tunap | grep -v "ssh|docker|nginx|postgres|redis"

# Verificar crontabs de todos os usuários
sudo crontab -l -u root
sudo crontab -l -u deploy
sudo cat /etc/crontab
sudo ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

# Arquivos modificados nas últimas 24h (excluindo /proc e /sys)
sudo find / -xdev -mtime -1 -type f 2>/dev/null \
  | grep -v -E '/proc|/sys|/tmp/.docker|/var/log' | head -30

# Verificar usuários com login recente
last | head -20
sudo lastlog | grep -v "Never"

Não quer configurar manualmente?

Implante o VPS em menos de 5 minutos com a Runstack. Infraestrutura da OPEN Datacenter, com servidores em São Paulo.

Perguntas frequentes

Causa comum: jobs de cron pesados (backup, indexação, logrotate) executando em horário de pico. Verifique: crontab -l e /etc/cron.d/. Outra causa: contention de recursos no hypervisor (vCPU steal time alto). Verifique com top, a coluna %st (steal time) acima de 10% indica que a VPS física está sobrecarregada.

CPU steal (%st no top/htop) é o tempo que a sua vCPU ficou aguardando a CPU física enquanto outros VMs no mesmo host tinham prioridade. Valores acima de 10% indicam oversubscription no hypervisor, o host físico tem mais vCPUs prometidas do que pode entregar. Nesse caso, abra chamado no suporte ou migre para outro plano.

Teste o TTFB da sua aplicação com curl -w "%{time_starttransfer}" -o /dev/null URL. Depois teste uma página estática do Nginx ou um endpoint de health check simples. Se o endpoint simples é rápido mas a aplicação é lenta, o problema é na aplicação. Se ambos são lentos, o problema é no servidor.

Processo com memory leak que foi crescendo até consumir toda a RAM, causando swap pesado. Logs runaway que encheram o disco. Ou processo travado em D state acumulando. Reiniciar resolve o sintoma mas não a causa, monitore após o reboot para identificar o que volta a crescer e configure limites (ulimit, docker memory limits) para evitar a recorrência.

Somente se o gargalo for RAM. Verifique: se free -h mostra "available" próximo de zero e swap sendo usado, upgrade de RAM ajuda. Se CPU está em 100% ou I/O wait alto, mais RAM não resolve. Diagnostique primeiro, upgrade sem diagnóstico pode ser desperdício.