Reading a VPS Spec Sheet: What vCPU, Steal Time and IOPS Caps Actually Mean in Practice

Every VPS pricing page in 2026 sells the same four numbers: 2 vCPU, 4 GB RAM, 80 GB NVMe, 1 Gbps. Those numbers are a ceiling, not a contract. Two instances with an identical line item can differ by 3x in sustained throughput, 10x in 4k random write IOPS and 8x in p99 SSH latency, because what you buy is a set of allocation policies the provider never prints. This guide decodes each line of the spec sheet into the mechanism behind it — cgroup quota, hypervisor scheduler, IOPS throttle, token bucket — and gives you commands to measure the difference in ten minutes.

The framing matters more than the vocabulary. A “2 vCPU” label resolves to one of two very different products: a KVM guest whose vCPUs are ordinary Linux threads on a host CPU set, or an LXC/OpenVZ container whose processes are throttled by cpu.max on a shared kernel. If you are weighing the second model for burstable work, see cloud VPS benefits. Everything below assumes you know which you are measuring.

vCPU: A Thread, A Quota, or A Promise

A vCPU is one virtual CPU presented to the guest. In KVM it maps to a QEMU vCPU thread scheduled against real hardware threads; in a container it maps to a cgroup CPU quota in microseconds. In both cases the label “1 vCPU” says nothing about how much of a physical core you get per second, nor how many tenants contend for that core. That is why nproc is the least informative command on a VPS.

The measurable proxy is steal time — the fraction of wall-clock time your vCPU was runnable but the hypervisor ran someone else. It appears as %steal in top and st in vmstat. A host selling 8 vCPUs per physical core shows 0-2% steal at 3 a.m. and 15-30% at 8 p.m.; the same plan on a 2:1 host stays under 3% all day. That difference is worth more than four extra vCPUs on the pricing page, and costs nothing to check on a trial.

Reading Steal Time Without Fooling Yourself

Idle steal reads near zero even on the most oversubscribed host, because an idle guest is not asking for CPU. Load the instance first: run sysbench cpu --threads=$(nproc) --time=60 run and sample vmstat 1 60 in parallel, averaging the st column over the middle 40 samples. A 4 vCPU plan averaging 12% steal delivers roughly 3.5 vCPUs; at 25%, about 3.

Second trap: steal is computed per-vCPU, so a single-threaded benchmark on a 4-vCPU guest can report 0% while three vCPUs starve. Saturate every vCPU when measuring, then run single-threaded separately to capture peak clock — many hosts bin high-clock cores for single-thread and low-clock cores for density, so an accurate lscpu model name still hides the boost ceiling you actually reach.

IOPS Caps: The Number That Decides Your Database

Almost every budget VPS enforces a per-instance IOPS throttle in the block layer — blkio weights in cgroup v1, io.max in v2, or an out-of-tree QEMU throttle group. Entry tiers typically cap at 2,000-3,000 IOPS; NVMe plans lift to tens of thousands. But the mechanism matters as much as the number: a token bucket lets you burst at 30,000 IOPS for seconds, then pins you to 500 for a minute. Your first fio run looks excellent; your twentieth does not.

Throttled I/O shows up as latency before it shows as a throughput number. When the bucket empties, requests queue in the guest and iowait climbs while the device looks idle — the classic signature of a cap rather than a slow disk. Test with a 60-second sustained run, not five, and read p99 as well as IOPS.

The Spec Sheet, Translated

Printed line	Mechanism behind it	How to verify in 60s
2 vCPU	Scheduler thread or cpu.max quota, shared	vmstat st column under full load
Dedicated vCPU	CPU pinning (taskset/cpuset) on the host	Steal stays <1% at peak hour
NVMe 80 GB	Shared NVMe with io.max throttle	60s fio randwrite, check p99 latency
1 Gbps port	Token bucket, 24h average quota	iperf3 to a public server for 60s
4 GB RAM	Ballooning + KSM overcommit	free -h idle vs under pressure
Unmetered transfer	Rate limit, not byte limit	Sustained download never exceeds port cap

Read the table as questions to ask the provider, not a checklist to admire. Any vendor who cannot state the enforced IOPS cap or whether the vCPU is pinned versus time-sliced is either reselling without visibility or choosing not to answer.

Seven Commands That Separate Providers

Run these on a trial instance at both off-peak and peak hours. The comparison is the product; a single 3 a.m. number tells you nothing about a 6 p.m. request spike.

# 1. What CPU, what virtualisation, how many threads
lscpu | grep -E 'Model name|^CPU\(s\)|Thread|Hypervisor'
systemd-detect-virt

# 2. Steal under full saturation (avg middle 40 samples of st)
sysbench cpu --threads=$(nproc) --time=60 run &
vmstat 1 60 | awk 'NR>10 && NR<51 {s+=$15; n++} END {printf "steal=%.1f%%\n", s/n}'

# 3. Sustained random write: IOPS + p99, reveals the throttle bucket
fio --name=rw --rw=randwrite --bs=4k --iodepth=32 --size=1G --runtime=60 \
    --time_based --output-format=json \
  | jq '{iops:.jobs[0].write.iops, p99_us:.jobs[0].write.clat_ns.percentile["99.000000"]}'

# 4. Memory honesty: committed vs available
free -m; grep -E 'Commit|Balloon' /proc/meminfo

# 5. Port speed ceiling
iperf3 -c ping.online.net -P 4 -t 30

# 6. Path quality to your users
mtr -rwzbc 100 1.1.1.1

# 7. Real single-thread peak clock
grep MHz /proc/cpuinfo | sort -n | tail -1

Interpret them together. A 4 vCPU plan reporting 12% steal is a 3.5 vCPU plan; a 1 Gbps port that plateaus at 94 Mbps under iperf3 is a 100 Mbps port with better marketing; a fio run whose first ten seconds hit 40,000 IOPS and whose last forty sit at 600 is a burst-credit throttle, not an NVMe drive.

Normalising Across Plans and Price Points

Raw IOPS is not comparable between a $6 plan and a $40 plan. Divide throughput by vCPU count for per-core efficiency, and by monthly price for cost efficiency — the two rankings often differ, and only one matters for your workload. A plan with half the raw IOPS but stable p99 beats a nominally faster one that collapses at peak. Report p99 and max, never mean alone.

Finally, re-run the suite after 30 days of production traffic. Hosts drift as providers fill boxes, and a plan that measured clean can move to a busier node during a maintenance window. To compare verified configurations rather than marketing copy, the VPS configurations listed here use the terms this guide defines.

What the Spec Sheet Cannot Tell You

Three operational properties decide more incidents than any spec: real snapshot restore time, control-plane latency under load, and support first-response at 2 a.m. None appear on the pricing page, and all are measurable during a trial if you deliberately break something.

Treat the spec sheet as the ceiling, and these commands as the floor you actually live with. Buy the floor.