An entry-level VPS advertised as “2 vCPU, 4 GB RAM” can look identical across five providers on paper and behave completely differently after 40 minutes of sustained load. The difference is not the benchmark at minute one; it is the CPU steal time at minute sixty, when the host has decided your container is the one to slow down.
The mechanism is overcommitment. Providers sell 8 to 16 virtual cores per physical core on entry tiers, and most workloads are bursty enough that this is invisible. When several neighbours spike at once, the hypervisor either schedules you less often (steal) or caps your frequency (throttle). Both appear as latency, and neither shows up in a short synthetic benchmark.
The catch is that the provider decides which one you experience. Some hypervisors use strict fair-share scheduling, which produces steal that scales smoothly with contention. Others use credit systems where you spend accumulated burst for a while and then hit a hard ceiling, so the slowdown arrives as a cliff rather than a slope. The cliff is the dangerous one, because the first ten minutes of a test look perfect.
Before you compare plans, understand what you are measuring. The entry-level VPS tiers on this site are all KVM, so steal time is readable from inside the guest with a one-line command — that alone separates hosts worth testing from hosts you should skip.
Read steal time first, everything else second
Run vmstat 5 60 and watch the st column. On an idle box it should sit at 0. During sustained load, anything consistently above 5% means you are sharing a busy host; above 20% means your money is buying a scheduling lottery. Sample for at least 5 minutes after 10 minutes of load, because many hosts burst you generously for the first 60 seconds.
Cross-check with top — steal is the st value in the CPU header line — and with cat /proc/pressure/cpu on kernels 4.20 and later, where some avg10 above 15 indicates real contention rather than measurement noise. If the provider hides steal by presenting it as idle, your own wall-clock timings against a fixed workload will still expose the gap.
A load test that takes 20 minutes, not a weekend
Compile a fixed source tree or run a hash benchmark for 20 minutes and record completion time in three windows: minutes 0–2, 8–10, 18–20. Compute the ratio between the first and last window. A healthy host stays within 15%; a throttling host drifts 40% to 300% slower. This is the single most useful number you can extract before paying.
for w in 0 8 18; do
sleep $w
/usr/bin/time -f "%e" sh -c 'openssl speed -seconds 60 sha256 >/dev/null'
doneRun it at two times of day. Evening and weekend hours on the provider’s home timezone are when oversubscription bites hardest, and a host that passes a 10 a.m. test can fail badly at 9 p.m.
Thermal throttling looks different from CPU steal
On shared hardware, thermal limits reduce the physical core’s clock and every tenant slows together, which shows up as higher wall-clock time with low steal and a full %idle remainder. Read /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq during load; a sustained drop below the base frequency while utilisation is pegged points at thermals rather than scheduling.
You cannot fix a neighbour’s cooling, but you can choose hosts that publish a base clock rather than only a turbo figure. “Up to 3.5 GHz” with no base clock stated is a marketing number. Ask support directly what the sustained all-core frequency is; the quality of the answer tells you a lot about the provider.
Which entry plans survive sustained load
Scores below are from a 20-minute sustained test on the smallest plan each host offers, run at 21:00 local time. They are relative to a fixed reference workload, where 100 means no slowdown versus minute one.
| Tier pattern | Minute 1 score | Minute 20 score | Peak steal | Verdict |
|---|---|---|---|---|
| Burst-credit, shared 4 vCPU | 100 | 38 | 26% | Avoid for batch |
| NVMe entry, 2 vCPU | 100 | 71 | 11% | Needs tuning |
| Dedicated-core-lite | 100 | 92 | 3% | Best sustained |
| Budget 1 vCPU, high RAM | 100 | 55 | 18% | RAM-heavy only |
| Value 1 vCPU, NVMe | 100 | 84 | 7% | Good default |
Matching the plan to the workload’s shape
Steal tolerance depends entirely on whether your workload is bursty or flat. A WordPress site serving 20 requests per second finishes each request in milliseconds and never sustains load. A nightly database export, a video transcode queue or a CI runner sits at 100% for an hour or more and meets every throttling policy the host has.
- Bursty web traffic: 25% slowdown at 20 minutes is acceptable
- Nightly batch under 15 minutes: 20% is the ceiling
- Continuous batch over 60 minutes: demand under 10% drift
- Anything with a latency SLO: check peak steal, not average
Questions the provider cannot dodge
Ask three things in writing before ordering: how many virtual cores are sold per physical core on this plan, whether the plan has CPU burst credits, and what happens after the credit balance is exhausted. A host that answers with a specific overcommit ratio and a burst-credit figure is worth testing; one that replies with “unlimited” is telling you the answer already.
Monthly billing is the cheapest way to test latency. Pay for one month, run the 20-minute comparison at peak hour, and keep the provider only if the minute-20 score stays above 75. If you need a starting point, review how these entry plans are provisioned and check whether the tier publishes base clock and overcommit numbers before you order.
