Sizing a VPS from real workload signals

Assumptions, and when this guide does not apply

The method assumes a Linux server (physical, VM or container host) that already runs the workload, or a staging copy you can load-test. It assumes you have shell access and can install the sysstat package, which provides sar, iostat and pidstat.

It does not apply directly when:

• There is no workload yet. Start on a small size, load-test with realistic traffic, then apply this guide to the test results.
• The load is very spiky (peak more than about 3x the quiet level). Sizing one VPS for peak will leave it idle most of the time; read Shared vs VPS vs cloud vs bare metal first.
• The workload is GPU-bound. Use GPU memory for LLM inference.

The method in five steps

1. Turn on history. Install sysstat and enable its collector (on RHEL-family systems systemctl enable --now sysstat; on Debian and Ubuntu set ENABLED="true" in /etc/default/sysstat). It samples every 10 minutes by default, which is enough for sizing.
2. Capture a busy window. Keep at least 7 days, 14 if you have a weekly cycle, and include a known busy period (campaign, month-end, release).
3. Find the busy hour. For each resource, take the 95th percentile of the busiest hour, not the monthly average. Averages hide the hour that hurts.
4. Apply headroom. Divide each busy-hour peak by its target utilization from the headroom table below.
5. Round up to a real size and check the next constraint. A size with enough CPU but too little memory is the wrong size. The binding resource sets the plan.

The VPS sizing tool does steps 4 and 5 from the numbers you collect.

CPU: run queue, steal and per-process use

CPU percentage alone misleads on virtual machines. Read four numbers together:

• Run queue (r in vmstat). Processes running or waiting for a CPU. If r is regularly above the vCPU count at peak, work is queuing.
• Load average. On Linux it counts runnable tasks and tasks in uninterruptible sleep, usually waiting for disk. A load of 8 on a 4 vCPU server with idle CPU is a storage problem, not a CPU problem.
• Steal (st in vmstat, %steal in sar -u). Time your vCPU was ready to run but the hypervisor ran something else. As a rule of thumb, sustained steal above about 5% deserves a question to the provider; above about 10% means you are not getting the CPU you size for, and a larger instance of the same class may not fix it.
• Per-process CPU (pidstat -u). Tells you whether one single-threaded process is pinned at 100% of one core while the rest idle. Adding vCPUs does not help a single-threaded bottleneck.

Also read /proc/pressure/cpu. The kernel's pressure stall information reports the share of time at least some tasks were waiting for CPU over 10, 60 and 300 seconds. A some avg60 that climbs during the busy hour is direct evidence of CPU shortage.

Memory: available memory, page cache, swap and OOM

Linux uses free memory as page cache, so "free" is usually small and that is healthy. Size from these instead:

• MemAvailable in /proc/meminfo (the available column of free -m): the kernel's estimate of memory available for new work without swapping. Peak used memory is MemTotal - MemAvailable.
• Process RSS. ps -eo pid,comm,rss --sort=-rss lists resident memory per process. RSS counts shared pages in every process that maps them, so adding up RSS for 20 PHP-FPM workers overstates their total. For a fairer figure use PSS from /proc/PID/smaps_rollup.
• Page cache you depend on. Databases and file servers rely on the cache to avoid disk reads. If the hot data set is 12 GB and only 4 GB is left for cache, reads go to disk and latency rises with no error message.
• Swap activity, not swap used. Swap used with si/so (in vmstat) near zero means cold pages were parked there, which is fine. Sustained non-zero swap-in at peak means the working set does not fit.
• OOM kills. journalctl -k | grep -iE 'out of memory|oom-kill'. One OOM kill in the sample window is a sizing failure, whatever the averages say.

Disk: IOPS, latency, queue size and capacity

Run iostat -x 5 during the busy hour and read these columns for the data volume:

• r/s and w/s: read and write operations per second. Compare the peak with the volume's stated IOPS limit, which is Confirmed at quote for any plan.
• r_await and w_await: average milliseconds per request including queue time. Local NVMe usually serves small requests well under a millisecond; network block storage takes longer. What matters is the trend: if await rises at peak while r/s and w/s flatten, you have hit a limit.
• aqu-sz: average queue length. A queue that grows at peak confirms saturation.
• %util: treat with care. The iostat manual notes that for devices serving requests in parallel, such as RAID arrays and modern SSDs, it does not reflect their performance limits. 100% util on an NVMe drive can still have spare capacity.

%iowait is CPU idle time while I/O is outstanding. It hints at storage waits but drops to zero when the CPU is busy with other work, so confirm with await and /proc/pressure/io. Use pidstat -d 5 to find which process does the I/O.

For capacity, measure growth per month from df history and project 12 months. Add room for the things that temporarily double data: database dumps before upgrades, table rewrites, log bursts and restore staging.

Network: peak rate, monthly egress and connections

sar -n DEV 5 shows received and transmitted kB per second per interface. You need two numbers: the busy-hour peak (to size the port) and the monthly outbound total (to check the transfer allowance).

For connections, ss -s summarizes TCP states. Thousands of connections in TIME-WAIT are normal for busy HTTP servers; a growing count of established connections that never close points to a client or keep-alive problem rather than a sizing problem.

Commands to collect the evidence

Run these during the busy hour. Each samples every 5 seconds for one minute; increase the count for a longer view. History from the sysstat collector is read with sar and a -f file for past days.

# CPU: run queue (r), iowait (wa), steal (st)
vmstat -w 5 12
sar -u 5 12            # %user %system %iowait %steal
sar -q                 # load average history for today
pidstat -u 5 12        # CPU per process
cat /proc/pressure/cpu

# Memory: available, swap activity, biggest processes, OOM kills
free -m
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo
sar -W 5 12            # pages swapped in and out per second
ps -eo pid,comm,rss --sort=-rss | head -15
journalctl -k --since "-14 days" | grep -iE 'out of memory|oom-kill'
cat /proc/pressure/memory

# Disk: IOPS, latency, queue, per-process I/O, capacity
iostat -x 5 12
pidstat -d 5 12
df -h
cat /proc/pressure/io

# Network: throughput per interface, TCP summary
sar -n DEV 5 12
ss -s

Label each saved output with the date and the event it covers (for example "campaign launch, 19:00-21:00").

Reading the signals

Headroom rules

Headroom covers what the sample did not see: growth, a heavier day, a deploy, a backup running in the busy hour. These are planning defaults; tighten them only when you have long history and an easy resize path.

Worked example: WordPress and WooCommerce

Worked example: a Node.js or Python API

Worked example: a PostgreSQL database

Sizing checklist

• sysstat history enabled and at least 7 days collected, including a busy period.
• Busy-hour 95th percentile recorded for CPU, memory used, disk IOPS and await, and network.
• Steal checked; any sustained value above about 5% noted.
• No OOM kills and no sustained swap-in in the window, or the cause understood.
• Per-process CPU and memory known for the main services (workers, database, cache).
• Deploy overlap included in the memory budget.
• Disk growth per month measured and projected 12 months.
• Monthly egress in TB calculated from the average Mbit/s.
• Headroom applied per resource, and the binding resource identified.
• Numbers entered in the VPS sizing tool and attached to the quote request.

Common mistakes

• Sizing from monthly averages. A 20% monthly average can hide a 95% busy hour. Size from the busy hour.
• Reading "free" memory. Low free memory is normal on Linux. Read MemAvailable and swap-in instead.
• Summing RSS. Shared pages are counted in every process, which overstates PHP or Python worker memory. Use PSS.
• Trusting %util on SSDs. It shows time with requests in flight, not how close the device is to its limit.
• Adding vCPUs to a single-threaded bottleneck. If one process sits at 100% of one core, more cores do nothing.
• Forgetting temporary disk needs. Major version upgrades, table rewrites and restores can need as much free space as the data itself.

Related