cloud VPS benefits<\/a>. Everything below assumes you know which you are measuring.<\/p>\n\n\n\nvCPU: A Thread, A Quota, or A Promise<\/h2>\n\n\n\n
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<\/code> is the least informative command on a VPS.<\/p>\n\n\n\nThe measurable proxy is steal time \u2014 the fraction of wall-clock time your vCPU was runnable but the hypervisor ran someone else. It appears as %steal<\/code> in top<\/code> and st<\/code> in vmstat<\/code>. 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.<\/p>\n\n\n\nReading Steal Time Without Fooling Yourself<\/h2>\n\n\n\n
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<\/code> and sample vmstat 1 60<\/code> in parallel, averaging the st<\/code> column over the middle 40 samples. A 4 vCPU plan averaging 12% steal delivers roughly 3.5 vCPUs; at 25%, about 3.<\/p>\n\n\n\nSecond 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 \u2014 many hosts bin high-clock cores for single-thread and low-clock cores for density, so an accurate lscpu<\/code> model name still hides the boost ceiling you actually reach.<\/p>\n\n\n\nIOPS Caps: The Number That Decides Your Database<\/h2>\n\n\n\n
Almost every budget VPS enforces a per-instance IOPS throttle in the block layer \u2014 blkio weights in cgroup v1, io.max<\/code> 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<\/code> run looks excellent; your twentieth does not.<\/p>\n\n\n\nThrottled I\/O shows up as latency before it shows as a throughput number. When the bucket empties, requests queue in the guest and iowait<\/code> climbs while the device looks idle \u2014 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.<\/p>\n\n\n\n