Step-by-step: Choose the Right VPS Size for Your Project

Hospedagem & VPS · By · Published on · Updated on · 9 min read

Server racks lit by blue LEDs in a data center
Server rack in a data center representing VPS and hosting infrastructure Photo: panumas nikhomkhai / Pexels

Choosing the right VPS size for your project means translating real metrics into CPU, RAM, disk, and network requirements. This practical tutorial walks you through measuring, testing, and validating capacity so you avoid underprovisioning and waste, with simple checks and objective criteria to decide with confidence.

Prerequisites

Before you begin, make sure you have a few items that make sizing objective. Some steps require root access and will generate synthetic load for testing.

Have an environment that represents production, real usage data, and permission to run measurement tools. Define simple performance goals: target latency, error rate, and peak windows.

  • SSH access to the current server or a test environment
  • Permission to install utilities (sysstat, iostat, ab)
  • A window to collect metrics during peak hours
  • Test endpoint URLs and a representative database
  • Basic SLOs: p95 latency, error rate, throughput

1) Define the project objective and load profile

Map how the application consumes resources. Classify components by load type: CPU, memory, disk, or network.

Web apps and APIs are often CPU- and network-bound. Databases suffer from I/O. Processing jobs are CPU- or memory-heavy.

List critical endpoints, queues, and jobs. Correlation and logs help pinpoint bottlenecks accurately. See the structured logs guide.

  • Synchronous Web/API: CPU and concurrent connections
  • DB/reports: I/O and memory for caches
  • Queue/processing: CPU and temporary disk
  • Streaming/uploads: network and disk for buffering

2) Measure CPU, memory, and disk on the current environment

Collect real metrics for several minutes during a representative period. Enable telemetry carefully in production.

Watch: CPU usage by mode, run queue, steal time, memory and swap usage, iowait, and disk IOPS. These reveal the limiting resource.

# 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) Estimate expected concurrency and throughput

Translate business traffic into technical concurrency. Use forecasted peaks, campaign windows, and busiest times. Calculate the ratio of requests per second to average response time to estimate concurrent connections.

For asynchronous jobs, estimate items per minute and average time per item to infer how many concurrent workers are needed.

Load type How to estimate concurrency Base metric
Web/API Req/s × average response time ≈ active connections p95 latency and peak rate
Queue/Jobs Items/min × average time per item ≈ active workers Average job duration
DB/Reports Concurrent queries and time per query p95 query time
Uploads/Streaming Number of connections × average bitrate Bandwidth per session

4) Convert signals into vCPU, RAM, disk, and network

Use your metric readings to guide a safe minimum size. Combine code tuning and sizing to reach an appropriate cost/benefit point.

Avoid fixed rules of thumb. Start small with a reasonable buffer and validate with representative load testing. For API and SQL bottlenecks, see the guide on reducing API latency and SQL optimization.

Observed signal Interpretation Recommended VPS adjustment
CPU user > 70% sustained; run queue > vCPU CPU is the bottleneck Increase vCPU or optimize the hottest endpoints
Steal time > 5% Host is overloaded / CPU is shared Prefer dedicated vCPU or move to another host
Memory > 80% with active swap Memory is the bottleneck Add RAM or reduce caches/footprint
iowait > 10% or high disk latency I/O is the bottleneck Use faster SSD/NVMe; increase IOPS; separate volumes
Network near contracted limit Network is the bottleneck Increase bandwidth, optimize payloads, compress, use a CDN

5) Choose appropriate storage and network

The right disk can make a big difference for databases and queues. Proper networking prevents kernel queues and timeouts under load.

Balance performance with durability and cost. Disk swaps may require planned downtime.

  • SATA SSD: good cost/benefit. NVMe: lower latency and higher IOPS.
  • Local volumes: fast but less resilient. Managed block storage: snapshots and configurable IOPS.
  • Separate OS, data, and logs to reduce contention.
  • Network is measured by Mbps or TB of traffic; check burst limits and egress policies.

6) Run a smoke load test before finalizing the purchase

Validate the candidate size with a simple test. This generates traffic — run it in staging or outside peak hours.

Measure p95 latency, error rate, and CPU/RAM during the test. Adjust and repeat until you meet 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) Plan for headroom and scaling strategies

Reserve headroom for traffic spikes and jitter. Headroom prevents long latency tails and degradation from GC, warmups, and bursts.

Define scaling criteria: vertical scaling for simplicity; horizontal scaling for resilience. Containers can simplify orchestration on top of VMs. See the Docker vs VMs high availability comparison.

  • Automate alerts for CPU, memory, and p95 latency.
  • Vertical scaling: adjust vCPU/RAM when metrics cross thresholds.
  • Horizontal scaling: load balancer and multiple smaller VMs.
  • Avoid overprovisioning: review average usage and peaks monthly.

8) Review costs and confirm with the provider calculator

Price varies by vCPU, RAM, disk, egress traffic, and region. Check the provider calculator before committing. Do not assume static numbers.

Test billing models: hourly, monthly packages, provisioned IOPS, and network egress. Compare regions and disk types. For additional cost-optimization ideas, see the guide on reducing cloud costs.

  • Compare regional pricing and storage types.
  • Evaluate whether dedicated vCPU is worth it for steady loads.
  • Start smaller, validate, then upgrade the plan.
  • Review cost optimizations periodically.

How to confirm it worked and common troubleshooting

After settling on a VPS size, validate in production with lightweight telemetry. If instability appears, check the signals below and adjust.

Common issues: high CPU steal, persistent swap, high iowait, and long connection queues. Address root causes before just adding resources. For slow APIs, see the guide on reducing API latency and SQL optimization.

  • High CPU steal: move to a less contended host or use dedicated vCPU.
  • Constant swap: add RAM and review caches and process limits.
  • High iowait: move to NVMe, increase IOPS, separate data/log volumes.
  • p95 latency spikes: enable compression, caching, and review N+1 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

Frequently asked questions

What's the difference between shared and dedicated vCPU?

Shared vCPU means the host CPU is multiplexed across multiple VMs, which can cause contention and increased steal time under load. Dedicated vCPU reserves physical CPU cycles for your instance, delivering more predictable performance for steady or latency‑sensitive workloads. Use measured metrics and controlled load tests to compare both options before committing to a configuration.

How much headroom should I keep when sizing a VPS?

Headroom depends on your application's load profile, tolerance for latency spikes, and burst patterns. Keep a comfortable buffer to absorb traffic variations, garbage collection, warmups and unexpected events, then validate that buffer with representative load tests. Reassess headroom after the first production week, major releases, or seasonal events and adjust scaling policies accordingly.

Is swap recommended in production?

Swap can act as a safety net to prevent out‑of‑memory crashes during short spikes, but relying on swap regularly degrades latency and throughput. Use a modest swap configuration for protection, monitor for persistent swap usage, and treat continuous swapping as an indicator to add RAM, optimize caches, or reduce memory consumption rather than increasing swap size indefinitely.

What is CPU steal time and why does it matter?

CPU steal time measures periods when your VM is ready to run but the hypervisor cannot schedule it because the host is contended. High or recurring steal causes unpredictable slowness and can break latency SLOs. If steal appears in your metrics, consider dedicated vCPUs, a less contended host family, or redistributing work horizontally to reduce dependence on a single VM.

How do I choose between SATA SSD and NVMe for a database?

Choose storage based on observed I/O behavior: if monitoring shows high iowait, long I/O queues, or latency that violates SLOs, NVMe typically provides lower latency and higher IOPS suited for databases. For light I/O workloads where latency isn't critical, SATA SSD can be cost‑effective. Always validate the choice with targeted load tests and production‑representative monitoring.

Want to validate your sizing with a guided test?

I can help turn your metrics into an objective, tested VPS specification with a growth plan that avoids waste.

Talk about your project

See also