Como dimensionar um VPS sem pagar pelo que não usa

Subdimensionar significa escolher um plano menor do que a aplicação precisa. O sintoma aparece como lentidão sob carga, processos sendo encerrados por falta de memória, filas que não esvaziam e, no pior caso, indisponibilidade nos horários de maior tráfego. O custo aqui raramente vem na fatura: vem na forma de clientes que abandonam o carrinho, conversões perdidas e tempo da equipe apagando incêndio.

Superdimensionar é o erro oposto e o mais comum por medo do primeiro. Você contrata 8 vCPUs e 32 GB de RAM (memória de acesso aleatório) para uma aplicação que usa, na média, uma fração disso. A conta chega todo mês, o recurso ocioso não gera retorno e a sensação de segurança é falsa: capacidade parada não previne um pico mal distribuído, ela só encarece a operação.

O ponto de partida correto não é o plano mais barato nem o mais robusto, e sim o tamanho que cobre a carga típica com uma folga planejada. A boa notícia é que um VPS moderno permite ajustar esse tamanho depois, então o objetivo inicial é acertar a ordem de grandeza, não buscar a precisão perfeita de cara.

A unidade de CPU em um VPS é a vCPU (virtual CPU, ou núcleo virtual), uma fatia de um núcleo físico do servidor hospedeiro. A pergunta certa não é quantos núcleos a aplicação tem direito, e sim quanto trabalho de processamento ela faz por requisição e quantas requisições acontecem ao mesmo tempo.

Cargas diferentes têm perfis diferentes. Um site institucional ou um blog passam a maior parte do tempo esperando banco e disco, então são leves em CPU e uma a duas vCPUs costumam bastar. Já APIs que serializam muito JSON, aplicações que renderizam relatórios, processamento de imagem ou vídeo e workers de fila são intensivos em processamento e se beneficiam de mais núcleos, porque conseguem distribuir tarefas em paralelo.

Uma forma prática de estimar é pensar em concorrência: número de requisições simultâneas multiplicado pelo tempo de CPU que cada uma consome. Se as requisições são curtas, poucos núcleos atendem muitas conexões; se são longas e pesadas, cada núcleo segura menos requisições por vez. Na dúvida, comece modesto e observe a métrica de uso de CPU sob carga real antes de adicionar núcleos.

A memória é onde o subdimensionamento dói mais rápido, porque quando a RAM acaba o sistema operacional começa a usar disco como memória virtual (swap) ou simplesmente mata processos. Some os consumidores principais: o runtime da aplicação e seus processos ou threads, o banco de dados, qualquer camada de cache em memória e o próprio sistema operacional com seus serviços.

Cada componente tem um apetite característico. Processos de aplicação como PHP-FPM, Gunicorn ou Node multiplicam o consumo pelo número de workers, então mais concorrência significa mais memória. Bancos como PostgreSQL e MySQL reservam buffers proporcionais ao volume de dados quente, e caches como Redis ou Memcached guardam o que você mandar guardar até o limite configurado. Reserve também algo na ordem de 0,5 a 1 GB para o sistema respirar.

Depois de somar, deixe folga. Uma regra de bolso saudável é dimensionar para que o uso típico fique em torno de 60 a 70 por cento da RAM total, sobrando margem para picos, para o cache de disco do sistema e para variações de carga. Memória que vive 95 por cento ocupada não é eficiência, é risco esperando um pico para virar incidente.

O disco precisa de uma conta em três partes: o que você guarda hoje, o que a operação gera continuamente e o quanto isso cresce. Os dados de hoje incluem o sistema operacional, a aplicação, dependências, o banco de dados e os arquivos enviados por usuários. Some tudo isso para ter a linha de base.

Logs e artefatos operacionais são o item mais subestimado. Logs de aplicação e de acesso, backups locais, imagens temporárias, caches de build e dumps de banco crescem em silêncio e enchem partições. Reserve espaço para eles e, igualmente importante, configure rotação e expurgo (logrotate, políticas de retenção) para que não acumulem indefinidamente.

Por fim, projete o crescimento ao longo do tempo de contrato. Estime o ritmo mensal de novos dados e multiplique pelo horizonte que você quer cobrir sem mexer no servidor, adicionando uma folga de 20 a 30 por cento. Vale lembrar que disco NVMe (memória não volátil expressa, padrão de armazenamento de altíssima velocidade) entrega ordens de grandeza mais IOPS que um HDD tradicional, o que muda menos o tamanho necessário e mais a velocidade com que o banco e a aplicação respondem.

Transferência de dados é o volume total que entra e sai do servidor no mês, normalmente medido em terabytes. Para estimar, parta do número de visitantes ou requisições e multiplique pelo tamanho médio das respostas: páginas, imagens, arquivos estáticos e respostas de API. Some o tráfego de saída de coisas como streaming, downloads e replicação, que costumam dominar a conta quando existem.

Separe banda de transferência. Banda (medida em Mbps ou Gbps) é a velocidade do link e determina o pico instantâneo que você consegue servir; transferência é o acumulado do mês. Um servidor pode ter banda generosa e ainda assim estourar a cota de transferência se o volume mensal for alto, então olhe os dois números.

Se você usa uma CDN (Content Delivery Network, rede de distribuição de conteúdo) para servir estáticos, boa parte do tráfego pesado nem toca o VPS, o que reduz bastante a transferência na origem. Considere esse alívio na estimativa para não contratar uma cota muito maior do que a necessária.

Toda estimativa inicial é uma hipótese, e a melhor forma de confirmá-la é medir o uso real. Acompanhe métricas de CPU, memória, disco e rede ao longo de dias e semanas, observando não só a média mas os horários de pico e os padrões sazonais, como campanhas, fechamento de mês ou lançamentos. São os picos, e não a média, que definem se o dimensionamento aguenta.

Com dados em mãos, ajuste. Se o uso típico vive baixo e os picos são confortáveis, há espaço para reduzir e economizar. Se algum recurso encosta no teto com frequência, é hora de crescer naquele eixo específico, e não em tudo de uma vez. Escalar com base em medição evita tanto a conta inflada quanto a surpresa desagradável.

Defina uma folga explícita para picos: mirar uso típico na faixa de 60 a 70 por cento dos recursos deixa margem para um aumento súbito de tráfego sem degradar a experiência. Para eventos previsíveis e excepcionais, vale redimensionar temporariamente para cima e voltar ao tamanho normal depois, pagando o reforço apenas pelo período em que ele realmente é necessário.

Resumindo em passos: primeiro, identifique o perfil da carga (leve em CPU como um site, ou intensiva como APIs e workers) e estime vCPUs pela concorrência e pelo tempo de processamento por requisição. Segundo, some RAM de aplicação, banco, cache e sistema, dimensionando para uso típico em torno de 60 a 70 por cento. Terceiro, calcule disco como dados atuais mais logs e backups, mais crescimento projetado com folga.

Quarto, estime transferência pelo tráfego mensal e verifique a banda separadamente, descontando o que uma CDN absorve. Quinto, e mais importante, comece com a estimativa, meça o uso real por algumas semanas e ajuste para cima ou para baixo onde os números pedirem. Dimensionar não é um evento único, é um ciclo de medir e corrigir.

Esse ciclo fica muito mais simples quando a hospedagem ajuda. Na Heffer, você acompanha CPU, memória, disco e rede direto pelo painel, com armazenamento 100 por cento NVMe, datacenter Tier III em São Paulo e SLA (acordo de nível de serviço) de 99,9 por cento. E como o plano pode ser redimensionado conforme a demanda evolui, com suporte 24/7 e migração gratuita, dá para começar enxuto e crescer só quando os dados mostrarem que chegou a hora, sem pagar pelo que você não usa.