Como escolher CPU, memória e disco

Dimensionar uma VPS não é escolher o maior plano que cabe no orçamento. É descobrir qual dos três recursos — CPU, memória ou disco — vai chegar ao limite primeiro na sua carga, e deixar folga nesse. Errar para cima custa dinheiro todo mês. Errar para baixo custa uma indisponibilidade num horário ruim.

O método é sempre o mesmo: estime um ponto de partida, meça durante alguns dias de uso real e ajuste. Medição vale mais que qualquer tabela, inclusive a que está mais abaixo nesta página.

Os três recursos falham de formas diferentes

Antes de escolher números, entenda o que acontece quando cada recurso acaba. As consequências não são equivalentes.

Memória insuficiente derruba processos. Quando a RAM acaba, o kernel do Linux aciona o OOM killer e mata o processo que estiver consumindo mais — normalmente o seu banco de dados ou o seu servidor de aplicação. Não há degradação suave: o serviço simplesmente sai do ar. Se houver swap, o sistema sobrevive, mas trocando página com o disco, o que costuma deixar a aplicação dezenas de vezes mais lenta.

CPU insuficiente deixa tudo mais lento. As requisições ficam na fila e o tempo de resposta sobe, mas nada morre. É o tipo de saturação com que se convive por um tempo.

Disco cheio corrompe estado. Banco de dados não consegue gravar, log para de rodar, upload falha pela metade. Este é o mais fácil de prever e o mais bobo de sofrer.

A ordem prática de prioridade, portanto, é: dê folga na memória, aceite CPU justa, e acompanhe o disco de perto para não descobrir o limite quando ele estourar.

Meça o que você já tem

Se a aplicação já roda em algum lugar — outro provedor, uma máquina local, um container — os números estão à sua frente. Rode isto durante um período de pico, não às três da manhã.

Memória em uso, sem contar cache:

free -h

Olhe a coluna available, não a free. O Linux usa memória livre como cache de disco de propósito; free baixo não significa problema. available perto de zero, sim.

Verifique se o sistema está usando swap, o que indica pressão real de memória:

vmstat 1 5

As colunas si e so (swap in/out) devem ficar em zero. Valores constantes ali significam que a máquina está pequena para a carga.

Procure execuções passadas do OOM killer:

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

Para CPU, compare o load average com o número de núcleos:

nproc
uptime

uptime devolve três médias — 1, 5 e 15 minutos. Um load de 4,0 em 4 núcleos significa CPU 100% ocupada em média. Acima disso há fila. Abaixo de metade do número de núcleos, você está pagando por capacidade ociosa.

Para disco, olhe espaço e inodes, porque acabam separadamente:

df -h
df -i
du -sh /var/lib/* 2>/dev/null | sort -h | tail

O du mostra onde o espaço realmente está. Em servidores de aplicação, quase sempre são logs, banco de dados e arquivos enviados por usuários.

Pontos de partida por tipo de carga

Use isto apenas como chute inicial. Os valores pressupõem Linux; uma VPS Windows precisa de mais memória e mais disco só para o sistema operacional, o que está detalhado em Linux ou Windows: qual escolher.

Duas observações que importam mais que a tabela:

Banco de dados na mesma máquina que a aplicação muda a conta de memória, não a de CPU. PostgreSQL e MySQL trabalham melhor quando o conjunto de dados quente cabe em RAM. Se o seu banco tem 6 GB, uma VPS de 2 GB vai ler do disco a cada consulta.

Cada worker do seu servidor de aplicação consome memória. Um processo PHP-FPM ou um worker Puma ocupa entre 50 MB e algumas centenas de MB. Multiplique pelo número de workers configurados antes de escolher a RAM — é a conta que mais gente esquece.

Disco: separe dados de crescimento previsível

Disco é o recurso mais fácil de manter pequeno, porque muita coisa não precisa estar nele. Arquivos enviados por usuários, imagens, assets estáticos e backups antigos podem ficar em um bucket compatível com S3, fora do disco da VPS. Isso mantém o servidor enxuto e o backup do servidor rápido.

Controle o crescimento de log antes que ele controle você. Verifique o tamanho do journal e limite-o:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M

Para limite permanente, ajuste SystemMaxUse em /etc/systemd/journald.conf. Aplicações que escrevem log próprio em /var/log devem passar por logrotate com rotate e maxsize definidos.

Ajuste depois, com medição

Comece pelo tamanho modesto e cresça com base em dados. É mais barato subir um plano no mês seguinte do que pagar seis meses por CPU parada. Na EasyOps você adiciona CPU e memória sob demanda, com uma janela de manutenção curta — a decisão inicial não é definitiva. Ao criar o servidor, as outras escolhas envolvidas estão descritas em Criar sua primeira VPS.

Antes de aumentar o plano por lentidão, confirme qual é o gargalo. Muitos casos de "VPS lenta" são disco saturado, consulta sem índice ou processo em loop, não falta de CPU. Aumentar recursos nesses casos apenas encarece o mesmo problema; o caminho de diagnóstico está em VPS lenta: como diagnosticar.

Uma nota sobre o caminho inverso: reduzir disco não é uma operação segura em nenhum provedor, porque exige encolher o sistema de arquivos. Trate o tamanho do disco como uma decisão de sentido único e não superdimensione por reflexo — cresça quando precisar. Em caso de dúvida sobre a conta do seu cenário, consulte os preços ou falar com o suporte.