Passo a passo: como escolher o tamanho certo de VPS para o seu projeto

Hospedagem & VPS · Por · Publicado em · Atualizado em · 9 min de leitura

Racks de servidores iluminados com LEDs azuis em um data center
Rack de servidores em data center, representando infraestrutura para VPS e hospedagem Foto: panumas nikhomkhai / Pexels

Como escolher o tamanho certo de VPS para o seu projeto exige traduzir métricas reais em CPU, RAM, disco e rede. Neste tutorial prático, você segue um passo a passo para medir, testar e validar a capacidade necessária, evitando tanto o subdimensionamento quanto o desperdício, com verificações simples e critérios objetivos para tomar decisão com segurança.

Pré-requisitos

Antes de começar, garanta alguns itens que tornam o dimensionamento objetivo. Alguns passos exigem acesso root e gerarão carga sintética para testes.

Tenha um ambiente que represente a produção, dados de uso real e permissão para executar ferramentas de medição. Defina metas de desempenho simples: latência alvo, taxa de erros e janelas de pico.

  • Acesso SSH ao servidor atual ou ambiente de testes
  • Permissão para instalar utilitários (sysstat, iostat, ab)
  • Uma janela para coletar métricas em horário de pico
  • URLs de endpoints de teste e base de dados representativa
  • SLOs básicos: latência p95, taxa de erros, throughput

1) Defina objetivo e perfil de carga do projeto

Mapeie como a aplicação consome recursos. Classifique componentes por tipo de carga: CPU, memória, disco ou rede.

Aplicações web e APIs costumam ser limitadas por CPU e rede. Bancos de dados sofrem com I/O. Jobs de processamento são CPU ou memória intensivos.

Liste endpoints críticos, filas e jobs. Ter correlação e logs ajuda a identificar gargalos com precisão. Veja o guia de logs estruturados.

  • Web/API síncrona: CPU e conexões simultâneas
  • DB/relatórios: I/O e memória para caches
  • Fila/processamento: CPU e disco temporário
  • Streaming/uploads: rede e disco para buffering

2) Meça CPU, memória e disco no ambiente atual

Colete métricas reais por alguns minutos em horário representativo. Ative a telemetria com cuidado em produção.

Observe: uso de CPU por modo, run queue, steal time, consumo de memória e swap, iowait e IOPS do disco. Isso revela o recurso limitante.

# Ubuntu/Debian: instalar utilitários de medição
sudo apt-get update && sudo apt-get install -y sysstat apache2-utils

# Habilitar coleta do sysstat (sar)
if [ -f /etc/default/sysstat ]; then
  sudo sed -i 's/ENABLED=\"false\"/ENABLED=\"true\"/' /etc/default/sysstat
  sudo systemctl enable --now sysstat
fi

# CPU: uso por modo e run queue por 60s
sar -u 1 60
# Memória: livres, cache, swap por 60s
sar -r 1 60
# Disco: latência, IOPS, iowait por 10s
iostat -xz 1 10
# Visão rápida do sistema
vmstat 1 10

3) Estime concorrência e throughput esperados

Traduza o tráfego do negócio em concorrência técnica. Use picos previstos, campanhas e horários de maior uso. Calcule a razão entre requisições por segundo e o tempo médio de resposta para estimar conexões simultâneas.

Para jobs assíncronos, estime itens por minuto e tempo médio por item para inferir quantos workers simultâneos serão necessários.

Tipo de carga Como estimar concorrência Métrica base
Web/API Req/s x tempo médio de resposta ≈ conexões ativas Latência p95 e taxa de pico
Fila/Jobs Itens/min x tempo médio por item ≈ workers ativos Duração média por job
DB/Relatórios Consultas concorrentes e tempo por consulta Tempo p95 de query
Uploads/Streaming Taxa de conexões e bitrate médio Largura de banda por sessão

4) Converta sinais em vCPU, RAM, disco e rede

Use a leitura das métricas para guiar o tamanho mínimo seguro. Combine ajuste de código e dimensionamento para chegar ao ponto de custo/benefício adequado.

Evite números fixos. Comece pequeno com folga razoável e valide em teste de carga representativo. Para gargalos de API e SQL, veja ideias em como reduzir latência de APIs REST.

Sinal observado Interpretação Ajuste recomendado na VPS
CPU user > 70% sustentado; run queue > vCPU CPU é gargalo Aumente vCPU ou otimize endpoints mais quentes
Steal time > 5% Host sobrecarregado/CPU compartilhada Prefira vCPU dedicada ou outro host
Memória > 80% com swap ativa Memória é gargalo Mais RAM ou reduza caches/footprint
iowait > 10% ou latência alta do disco I/O é gargalo Use SSD/NVMe mais rápidos; aumente IOPS; separe volumes
Rede próxima do teto contratado Rede é gargalo Mais banda, otimizar payloads, compressão, CDN

5) Escolha armazenamento e rede adequados

O disco certo muda o jogo em bancos de dados e filas. A rede adequada evita filas no kernel e timeouts sob pico.

Combine desempenho com durabilidade e custo. Trocas de disco podem exigir parada planejada.

  • SSD SATA: bom custo. NVMe: baixa latência e IOPS elevados.
  • Volume local: rápido, mas menos resiliente. Bloco gerenciado: snapshots e IOPS configuráveis.
  • Separar SO, dados e logs reduz contenção.
  • Rede medida por Mbps ou TB de tráfego; verifique limites de burst e política de egress.

6) Faça um smoke test de carga antes da compra definitiva

Valide o tamanho candidato com um teste simples. Isso gera tráfego; execute em staging ou fora do horário de pico.

Meça latência p95, taxa de erros e uso de CPU/RAM durante o teste. Ajuste e repita até ficar dentro dos SLOs.

# Exemplo com ApacheBench (ab): 2000 requisições, 50 concorrentes
# Substitua pela sua URL de teste
ab -n 2000 -c 50 https://seu-dominio.test/health

# Dica: rode em uma máquina fora da VPS alvo para evitar viés
# Colete métricas em paralelo (em outro terminal)
sar -u 1 60 &
sar -r 1 60 &
iostat -xz 1 60 &
wait

7) Planeje margem de folga e estratégias de escala

Reserve folga para picos e jitter de tráfego. A folga evita caudas longas de latência e degradação por GC, warmups e bursts.

Defina critério de escala: vertical para simplicidade; horizontal para resiliência. Containers podem facilitar orquestração sobre VMs. Veja o comparativo Docker vs VMs para alta disponibilidade.

  • Automatize alertas por CPU, memória e latência p95.
  • Escala vertical: ajuste vCPU/RAM quando a métrica passar do limiar.
  • Escala horizontal: load balancer e múltiplas VMs menores.
  • Evite overprovision: revise mensalmente seu uso médio e picos.

8) Revise custos e confirme com a calculadora do provedor

O preço varia por vCPU, RAM, disco, tráfego e região. Consulte a calculadora do provedor antes de fechar. Não assuma valores estáticos.

Teste modelos de cobrança: por hora, pacote mensal, IOPS provisionado e egress de rede. Compare regiões e tipos de disco. Ideias adicionais de otimização estão em reduzir custos na nuvem.

  • Compare variação por região e por tipo de armazenamento.
  • Avalie se vCPU dedicada compensa em cargas estáveis.
  • Comece menor, valide, e então ajuste o plano.
  • Revise otimizações de custo periódicas.

Como confirmar que funcionou e solução de problemas comuns

Após definir o tamanho da VPS, valide em produção com telemetria leve. Se surgir instabilidade, verifique os sinais abaixo e ajuste.

Erros comuns: roubo de CPU alto, swap contínua, iowait elevado e filas longas de conexão. Trate a causa raiz antes de apenas aumentar recursos. Para APIs lentas, veja dicas de redução de latência e SQL.

  • CPU steal alta: migre para host menos contendido ou vCPU dedicada.
  • Swap constante: aumente RAM e revise caches e limites de processos.
  • iowait alto: mude para NVMe, aumente IOPS, separe volumes de dados/logs.
  • Picos de latência p95: ative compressão, cache e revise N+1 em queries.
# Verificações rápidas pós-go-live
# CPU: uso por modo e steal time por 30s
mpstat 1 30
# Memória e swap
free -h && vmstat 1 10
# Fila de execução e iowait
sar -q 1 10 && iostat -xz 1 10

Perguntas frequentes

Qual a diferença entre vCPU compartilhada e dedicada?

vCPU compartilhada divide o tempo de CPU física com outras VMs, podendo sofrer contenção (steal). Dedicada reserva ciclos previsíveis, útil para cargas estáveis ou sensíveis à latência. Se suas métricas mostram variação sem causa aparente, testar dedicada pode estabilizar a performance.

Quanta folga devo manter no dimensionamento da VPS?

Depende do perfil de carga e da tolerância a picos. Mantenha uma margem confortável para absorver variações e eventos inesperados, validando em testes de carga. Revise a margem com dados reais após a primeira semana e após eventos sazonais relevantes.

Swap é recomendada em produção?

Swap evita OOM em picos, mas degrada a latência quando usada continuamente. Use como proteção, com tamanhos moderados. Se o uso de swap vira rotina, o caminho certo é reduzir consumo de memória ou aumentar RAM, não apenas ampliar a swap.

O que é CPU steal time e por que importa?

Steal time é o tempo em que sua VM quer CPU mas o hypervisor não entrega, por contenção do host. Valores altos causam lentidão imprevisível. Se o steal time é recorrente, considere vCPU dedicada, outra família de host ou migrar a carga para máquina menos contida.

Como decidir entre SSD SATA e NVMe para o banco de dados?

Se seu banco apresenta iowait elevado, filas de I/O e latências acima do aceitável, NVMe ajuda por ter menor latência e IOPS maiores. Se a carga é leve e o gargalo não é I/O, SSD SATA pode bastar. Sempre valide com testes de carga e monitoração.

Quer validar seu dimensionamento com um teste guiado?

Posso ajudar a transformar suas métricas em uma especificação de VPS objetiva e testada, com plano de evolução sem desperdício.

Falar sobre seu projeto

Veja também