VPS lenta: como diagnosticar

"O servidor está lento" não é um diagnóstico. É um sintoma que pode vir de quatro recursos diferentes — CPU, memória, disco e rede — e cada um pede uma correção distinta. Aumentar o plano por palpite resolve por acaso em alguns casos e, nos outros, você paga mais e continua lento.

Este artigo é a ordem em que vale investigar, com o comando que responde cada pergunta e como ler a resposta.

Delimite o problema antes de abrir o terminal

Três perguntas economizam muito tempo:

• Lento para quem? Só para você, ou para todos os usuários? Se é só para você, suspeite de rede/DNS no seu lado antes do servidor.
• Lento desde quando? Se começou depois de um deploy, uma atualização ou uma mudança de configuração, a causa provável é essa mudança — não capacidade.
• Lento sempre ou em picos? Lentidão constante costuma ser recurso subdimensionado. Picos costumam ser um processo específico (cron, backup, indexação, crawler).

O painel mostra CPU, memória e disco ao vivo, o que ajuda a responder a terceira pergunta: acompanhe as métricas durante a janela em que a lentidão aparece e veja qual dos três recursos chega ao teto.

Leitura geral: carga e processos

Conecte via SSH e comece pelo panorama.

uptime
nproc

uptime mostra o load average de 1, 5 e 15 minutos. Esse número só faz sentido comparado ao número de vCPUs (nproc). Load 4,0 em uma máquina de 4 vCPUs é ocupação total sem fila; load 4,0 em 1 vCPU significa que há processos esperando a maior parte do tempo. Compare os três valores: se o de 1 minuto é muito maior que o de 15, o problema é agora e está subindo.

Depois, veja quem consome:

top -o %CPU

No cabeçalho do top, a linha %Cpu(s) é a parte mais informativa:

Se wa está alto e us baixo, aumentar vCPU não muda nada. Vá para a seção de disco.

Memória: "livre" não é o que parece

free -h

Não se assuste com pouca memória livre. O Linux usa memória sobrando como cache de disco de propósito — é a coluna buff/cache. A coluna que importa é available: é o quanto pode ser entregue a um novo processo sem paginar.

O sinal real de falta de memória é o swap em uso ativo:

vmstat 1 5

Olhe as colunas si e so (swap in/out). Zeradas, está tudo bem, mesmo que o swap tenha algum uso residual. Números constantes ali significam que o sistema está trocando páginas com o disco o tempo todo — a causa mais comum de "tudo ficou absurdamente lento de uma vez".

Falta de memória grave termina com processos mortos pelo kernel:

sudo dmesg -T | grep -i -E 'out of memory|killed process'

Se aparecer o OOM killer, o serviço que caiu não caiu por bug: faltou RAM. Aí a decisão é reduzir consumo (limitar workers do PHP-FPM, max_connections do banco, heap da JVM) ou subir memória.

Disco: espaço e latência são problemas diferentes

Primeiro o mais bobo e mais comum:

df -h
df -i

Disco cheio derruba banco de dados, impede log e trava deploy. E vale checar df -i: é possível ter espaço sobrando e esgotar inodes, quando há milhões de arquivos pequenos (cache, sessões, filas em arquivo). Se / estiver perto de 100%, procure o peso:

sudo du -xh --max-depth=1 / | sort -h | tail -15

Espaço resolvido, meça latência:

sudo apt install sysstat   # Debian/Ubuntu
iostat -xz 1 5

As colunas úteis são %util (quanto do tempo o dispositivo esteve ocupado), await (tempo médio de espera por requisição, em ms) e r/s + w/s. %util perto de 100 com await alto é gargalo de disco confirmado. Para descobrir o culpado:

sudo iotop -oa

Muitas vezes o culpado é uma query sem índice fazendo varredura sequencial, ou um log em modo debug. Nenhum dos dois se conserta com plano maior.

Rede: latência, DNS e conexões

ping -c 5 1.1.1.1
ss -s
ss -tan state established | wc -l

ping separa latência de perda de pacote. ss -s resume conexões: milhares em TIME-WAIT ou uma pilha de SYN-RECV indicam um padrão de tráfego que a aplicação não está dando conta de fechar, não banda insuficiente.

Se a página demora para "começar" e depois carrega rápido, teste resolução de nome — DNS lento parece servidor lento:

time dig +short api.exemplo.com

Vale conferir também se a lentidão intermitente não é tráfego indesejado chegando em portas que deveriam estar fechadas. Fechar o que não precisa estar aberto, com regras de firewall, reduz ruído e carga.

Antes de mudar qualquer coisa

Ajuste de kernel, troca de versão de banco e mudança de configuração de servidor web podem deixar o serviço pior — ou fora do ar. Tire um snapshot antes da mudança; a captura não exige downtime e dá um ponto de retorno conhecido.

Mude uma variável por vez e meça de novo com o mesmo comando. Duas alterações simultâneas tornam impossível saber qual delas ajudou.

Quando aumentar o plano é a resposta certa

Vale subir recursos quando a medição, e não a impressão, aponta saturação sustentada:

• us alto e constante com a aplicação já otimizada: mais vCPU.
• available baixo com si/so ativos, ou OOM recorrente: mais memória.
• %util de disco no teto com I/O legítimo: mais disco ou arquitetura diferente (mover arquivos estáticos e backups para Object Storage, por exemplo, alivia disco e I/O da VPS).

Se a conclusão for redimensionar, o critério de escolha está em como escolher CPU, memória e disco, e os valores em preços. Se os números não fecharem com o sintoma, traga a saída dos comandos ao falar com o suporte — medição concreta encurta o atendimento bastante.