Every VPS plan is described with numbers that appear to be guarantees: two cores, four gigabytes, one hundred gigabytes of disk. Almost none of those numbers describe a resource you exclusively control. What you actually receive depends on the allocation model underneath — whether the provider reserves capacity for you, or shares a pool among tenants and divides it fairly at runtime. The two models are not equally good or bad; they are priced differently and fail differently, and reading which one you are buying is the difference between a plan that holds up and one that quietly degrades.
This is a guide to reading allocation claims, and to the handful of kernel metrics that let you verify them from inside the VM.
Two models: reserve and fair-share
In a reserved allocation, the provider commits specific physical capacity to your instance for as long as it runs. A reserved one-core plan maps to a pinned physical core; reserved RAM is memory the hypervisor will not hand to another tenant; reserved disk is storage whose IOPS budget is earmarked. Reserved allocations cost more because idle capacity cannot be resold, and they fail predictably: when you exceed your reservation you get less than you asked for, but you never get less because someone else is busy.
In a fair-share allocation, the provider packs more instances onto a host than the sum of their nominal specs, on the assumption that not everyone peaks at once. Your nominal vCPU is a weighted share of a core; your memory is typically hard-limited per VM but the host may be overcommitted in aggregate; disk is a shared volume with a per-tenant throttle. Fair-share is cheaper because the provider monetises statistical idle time, and it fails in a distinctive way: performance depends on your neighbours, and it degrades precisely when the host is busiest, which is often when you are busiest too.
Neither is dishonest as long as it is disclosed. The problem is that the vocabulary on pricing pages does not distinguish them, so “2 vCPU” describes both a pinned pair of cores and a time-sliced fraction, at prices that differ by two or three times.
How to read what a provider claims
Start with the words the provider chose. “Dedicated” applied to CPU is meaningful when it is paired with a statement that the cores are pinned, and meaningless when it appears next to “shared” or “burstable” elsewhere on the same page. “Equal share” and “fair use” both indicate a pool. “Guaranteed” is only a real guarantee if the terms of service describe a remedy when the guarantee is not met.
Second, look at how the products are tiered. A provider offering a dedicated-core tier at roughly double the price of its standard tier, on identical nominal specs, is telling you by construction that the standard tier is fair-share. That is useful information: the price gap quantifies the reservation.
- “2 vCPU” — assume fair-share unless pinned cores are explicitly stated.
- “2 dedicated vCPU” — reserved, but check whether the whole core or a hyperthread is pinned.
- “Up to 4 vCPU burst” — fair-share with a burst ceiling and almost certainly a cooldown.
- “Guaranteed RAM” — usually a hard limit, which is the one thing fair-share hosts rarely overcommit visibly.
Third, ask in a ticket. “Is the CPU allocation pinned or time-sliced, and is the host oversubscribed?” is a question that a competent infrastructure team answers without hesitation. A vague or defensive reply tells you the answer anyway.
Why memory claims are usually the most honest
Memory overcommit is technically possible but operationally dangerous: hypervisors that hand out more RAM than physically exists rely on ballooning and swap at the host level, and the failure mode (mass eviction) is visible to every tenant at once. Most reputable providers therefore hard-cap RAM per VM even when they oversubscribe CPU. That makes the memory figure on a budget plan the most trustworthy number on the page, and it is one reason memory usually becomes your binding constraint before CPU does.
Disk is the opposite. Capacity is cheap and usually real; throughput and IOPS are shared on network-attached storage and are the resource most likely to be silently throttled. The allocation math on disk is about the throttle, not the size.
Measuring CPU: steal time is the tell
The kernel metric that most directly exposes a contended host is steal time: the percentage of wall-clock time your vCPU was runnable but the hypervisor gave the physical core to someone else. It is reported in /proc/stat as the steal column and in top and vmstat as st.
On a reserved allocation, steal time should sit close to zero. On a busy fair-share host it can drift into single digits and spike far higher during peak hours. A practical rule of thumb: brief spikes during host-wide events are tolerable; a sustained average above a few percent means you are paying for cores you are not receiving. Sample it over a full week, because a single afternoon tells you very little about a host whose load has a daily rhythm.
Cross-check with the load average and with actual work done, not just CPU percentage. If your application’s throughput drops while its CPU utilisation stays flat and steal climbs, the host is squeezing you. If utilisation and throughput both drop together, the bottleneck is probably inside your application.
Measuring IO: iowait and latency distributions
iowait is the time your CPUs spent idle waiting on storage to complete. It conflates your own slow queries with the host’s throttling, so it is suggestive rather than conclusive on its own — but a sustained iowait in double digits under light application load is a strong indication that the storage layer, not your code, is the constraint.
To separate your workload from the host’s behaviour, measure latency distributions rather than averages. Run fio with a small random-read queue depth, or simply time fsync calls in your application, and record the 95th and 99th percentiles at different times of day. On a shared volume, the tail latency inflates when neighbours are busy even if your average looks healthy. Compare a quiet period (early morning in the provider’s timezone) against peak — a widening gap between the two is the signature of fair-share storage.
Also watch the kernel’s block-layer counters for errors and retries; on network storage, retries before success show up as added latency long before they show up as failures. If p99 write latency is consistently several times the p50 across days, you are sharing.
What to do with the numbers
Measure for one billing cycle, then decide. If steal time and iowait tails are consistently low on a fair-share plan, you have found a well-managed host and are getting the cheap tier’s full value — this is common, and it is why fair-share plans are usually the correct purchase for small workloads. If they are not, you have three options: accept the degradation because the price reflects it, move the sensitive workload (usually the database) to a reserved tier while leaving the front end on fair-share, or migrate.
The common mistake is to buy a cheap fair-share plan, observe contention, and then throw resources at it — upgrading RAM or CPU on the same oversubscribed host, which raises cost without addressing the constraint. Allocation is a property of the host, not of your plan size.
The budget VPS comparison marks which plans state a reserved allocation and which are explicitly fair-share, so you can match the model to the workload before you deploy. Where the description is ambiguous, treat the cheaper option as fair-share and measure it — and if the measurements matter to your budget, the head-to-head plan breakdown is where to compare the premium a reservation actually costs.
