VPS lento? O que fazer: 6 sinais de que ficou pequeno

Meça CPU, memória, disco e conexões antes de pagar por mais máquina: 6 sinais mostram se o VPS ficou pequeno ou se o problema é só configuração.

Por Redação Eleven Host · @robson.direitodigital · 20 de outubro de 2026 · 6 min de leitura

VPS lento, o que fazer? Meça CPU, memória, disco e conexões antes de pagar por mais máquina: os 6 sinais abaixo mostram se o servidor ficou pequeno ou se o problema é só configuração.

Você digitou "vps lento o que fazer" porque o site demora, o sistema trava ou o servidor reinicia sozinho. Antes de contratar mais máquina, vale descobrir se o problema é falta de recurso ou configuração. Às vezes um índice de banco resolve; às vezes o projeto realmente cresceu além do plano. Este guia ajuda a separar uma coisa da outra com medições, não com palpite.

Os comandos valem para Ubuntu e Debian. Rode-os em horários diferentes, inclusive no pico de uso, porque um servidor "normal" às 4 da manhã não diz nada sobre as 14 horas.

Primeiro: meça antes de decidir

Anote os números de uma situação lenta e de uma situação normal. Sem essa comparação, qualquer ajuste é aposta. Para ver a visão geral:

• uptime
• nproc
• free -h
• df -h

uptime mostra a carga média (três valores: 1, 5 e 15 minutos), nproc mostra quantos núcleos o servidor tem, free -h mostra a memória e df -h mostra o espaço em disco.

Sinal 1: a carga fica acima do número de núcleos

Se a carga média do uptime fica de forma constante acima do valor de nproc, existem mais tarefas esperando o processador do que núcleos para executá-las. Veja quem está consumindo:

• top -o %CPU

Dentro do top, olhe a linha %Cpu(s):

• us alto: seus programas (aplicação, PHP, Node) estão usando muita CPU.
• wa alto: o processador espera o disco (veja o sinal 3).
• st alto: o processador foi "emprestado" a outra máquina virtual no mesmo hardware. Se isso for frequente, abra um ticket na área do cliente com os horários e as medições.

O que fazer: se um único processo domina, otimize ou corrija-o primeiro (consulta lenta, laço infinito, robô agressivo). Se vários processos legítimos somam a carga, o plano está pequeno para o trabalho.

Sinal 2: a memória acaba e o sistema usa swap o tempo todo

• free -h
• vmstat 1 5

Olhe a coluna available do free. Se ela vive perto de zero e a coluna si/so do vmstat (troca com o swap) não para de mudar, o servidor está trocando memória por disco, o que deixa tudo lento.

O sinal mais claro é o sistema encerrar programas por falta de memória. Procure:

• sudo journalctl -k | grep -i "out of memory"

Se aparecer "Out of memory: Killed process" (por exemplo, o banco de dados ou o PHP), a memória acabou de fato e o sistema matou um processo para se salvar.

O que fazer: reduza o que a aplicação carrega (número de workers, cache sem limite, plugins). Se mesmo enxuta ela não cabe, é hora de mais memória.

Sinal 3: o disco é o gargalo (espaço ou velocidade)

Espaço: df -h mostra a ocupação. Cuidado também com os inodes, que podem acabar com muitos arquivos pequenos mesmo com espaço livre:

• df -h
• df -i
• sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail

Velocidade: instale as ferramentas de monitoramento e observe a espera de disco.

• sudo apt install -y sysstat
• iostat -x 1 5

Se %iowait e a coluna %util ficam altos no iostat enquanto o site está lento, o disco não dá conta do volume de leituras e gravações (muito comum em banco de dados grande).

O que fazer: limpe logs antigos e arquivos temporários, configure a rotação de logs (logrotate), revise índices e consultas do banco. Se os dados cresceram além do armazenamento do plano, é preciso mais espaço.

Sinal 4: o banco de dados vira o ponto fraco

Páginas que demoram só quando mexem em dados costumam apontar para o banco. No MariaDB/MySQL, veja o que está em execução agora:

• sudo mysql -e "SHOW FULL PROCESSLIST;"

Muitas consultas paradas ou lentas ao mesmo tempo, ou o erro "too many connections", indicam que o banco está disputando CPU, memória e disco com a aplicação, tudo na mesma máquina.

O que fazer: ative o log de consultas lentas, crie índices para o que aparece nele e use cache. Se mesmo assim o banco disputa recursos com o site, uma opção é separar os dois em servidores diferentes, por exemplo com um banco gerenciado, como o 11SQL.

Sinal 5: as conexões e os processos não dão conta do pico

• ss -s
• ps aux --sort=-%mem | head

Veja quantas conexões estão abertas e quantos processos do servidor web ou da aplicação existem. Se nos horários de pico os visitantes recebem erro 502/503, tempo esgotado, ou a fila de requisições cresce, o servidor está recebendo mais pedidos do que consegue atender.

Descarte antes uma causa externa: acesso de robôs, ataque de força bruta, um laço de requisições da própria aplicação. Verifique os logs de acesso (por exemplo, /var/log/nginx/access.log) para ver de onde vem o volume.

O que fazer: ajuste o número de workers à memória disponível (mais workers do que a memória aguenta piora tudo), use cache de páginas e bloqueie tráfego abusivo. Se o tráfego é legítimo e constante, o plano é pequeno.

Sinal 6: você otimizou e a lentidão voltou em semanas

Este é o sinal mais importante. Se você já cuidou de consultas, cache e configuração e, mesmo assim, os mesmos sintomas retornam sempre que o projeto ganha mais usuários, o problema deixou de ser ajuste: é capacidade. Compare os números de hoje com os de três meses atrás. Se a curva só sobe, planeje a mudança antes da próxima campanha ou sazonalidade, não durante a crise.

Otimizar, subir de plano ou ir para dedicado?

• Um processo ou uma consulta domina o consumo: Otimizar primeiro
• Vários serviços legítimos esgotam CPU ou memória: Plano de VPS maior (confira antes como o upgrade funciona no seu provedor)
• Banco e aplicação disputam a mesma máquina: Separar em dois servidores ou subir de plano
• Carga alta e constante, muito acesso a disco, necessidade de hardware só seu: Avaliar servidor dedicado (bare metal)

Um servidor dedicado entrega o hardware inteiro para você, sem dividir com outras máquinas virtuais. Ele faz sentido quando a carga é alta, previsível e contínua. Para projetos em crescimento, o caminho mais comum é subir de plano de VPS antes. Antes de qualquer mudança de plano, mantenha o seu backup em dia.

Antes de migrar, faça backup completo e teste o novo servidor com seu próprio tráfego simulado.

Com os números em mãos, compare os planos. Ver planos de VPS

Perguntas frequentes

Meu VPS está lento: é sempre falta de recurso?

Não. Consultas sem índice, plugins pesados, cache desligado e robôs agressivos são causas frequentes. Meça antes de contratar mais.

Como sei se a memória é o problema?

Se available no free -h fica perto de zero, há uso intenso de swap ou aparecem mensagens "Out of memory" no log do sistema.

Adicionar swap resolve?

Ajuda a evitar que o sistema encerre processos, mas o swap fica no disco e é bem mais lento que a memória. É uma rede de segurança, não um substituto para mais memória.

Quando faz sentido ir para um servidor dedicado?

Quando a carga é alta e constante, o projeto precisa de hardware exclusivo ou o acesso a disco é intenso. Veja os modelos e as especificações na loja de servidores dedicados; a disponibilidade varia.

Como pedir ajuda se achar que o problema é da infraestrutura?

Abra um ticket no suporte com os horários da lentidão e a saída dos comandos deste guia. Isso agiliza a análise.

Precisa de hardware só seu para uma carga constante? Ver servidores dedicados