How Budget VPS Providers Oversell (And How to Tell If You're on an Oversold Node)

How overselling works

CPU: the core of the problem

A physical server with a 64-core EPYC processor might host VMs that collectively claim 200+ vCPUs. That is a 3:1 overcommit ratio, and it is considered conservative. Budget providers commonly run 4:1 to 8:1. The hypervisor (KVM, VMware, Proxmox) time-slices physical cores across VMs using a scheduler. When demand exceeds supply, your VM waits in a queue. That waiting time is called CPU steal, and it is the single most important metric for detecting overselling.

Red Hat's virtualization documentation considers 10:1 a "rough maximum" for CPU overcommit. The author of webhosting.de's analysis considers "significantly less sensible in production." A documented SQL server test on an overcommitted host showed throughput dropping from 25,200 transactions per minute to less than half when background load from other tenants activated.

RAM: the hidden deduplication

KSM (Kernel Same-page Merging) scans guest memory pages on the host and deduplicates identical ones into shared physical pages. Ten VMs running the same Linux distro share most of their kernel memory. Providers can save 30-60% of physical RAM this way. KSM has been in the Linux kernel since version 2.6.32.

The catch: there is no way to detect whether KSM is active from inside your VM. The Linux kernel documentation provides no guest-side detection mechanism. KSM operates within the host kernel and is invisible to guests.

Memory ballooning is the other mechanism. KVM's virtio_balloon driver dynamically reclaims unused RAM from idle guests and hands it to active ones. You can detect the balloon driver with lspci | grep balloon. If it shows "Red Hat, Inc Virtio memory balloon," the host can reclaim your RAM under pressure. Its presence does not mean it is actively squeezing you, but it means the capability exists.

Disk: thin provisioning

Thin provisioning allocates virtual disk space without reserving physical storage until data is actually written. A host with 10TB of physical NVMe might sell 30TB total across VMs. This works as long as aggregate actual usage stays under physical capacity. When it does not, write operations slow dramatically as the storage controller struggles. You cannot detect thin provisioning from inside the guest, but you can detect its consequences: rising I/O latency during write-heavy operations.

Bandwidth: the 95th percentile game

The 95th percentile billing method samples bandwidth every 5 minutes (~8,640 samples per month), discards the top 5% (~432 samples, covering about 35 hours of peak traffic), and bills on the next-highest value. Providers sell "1 Gbps unmetered" knowing most customers use a fraction of that capacity most of the time. Your individual traffic bursts are absorbed by the 5% discard window. The overselling happens at the aggregate level: the total advertised bandwidth across all VMs on a node far exceeds the node's uplink capacity.

How to detect overselling from inside your VPS

CPU steal time: the definitive test

The %st (steal) column in top, htop, and mpstat shows the percentage of time your vCPU was ready to execute but the hypervisor gave the physical core to another VM. This is the most direct overselling indicator available.

# Per-core steal over 30 seconds (the best diagnostic)
mpstat -P ALL 1 30

# CPU breakdown including steal
iostat -c 1 30

# Watch the 'st' column
vmstat 1 30

Thresholds (converged from Scout APM, GetPageSpeed, and LowEndTalk community consensus):

Benchmark consistency test

Run the same benchmark at different times of day. If results vary dramatically, the node has contention:

# Single-threaded CPU benchmark (run 3-5 times at different hours)
sysbench cpu --threads=1 run

# Look at "events per second" - should be consistent (<15% variation)

VPSBenchmarks.com measures this formally as "coefficient of variation" (standard deviation divided by mean). Their endurance tests run CPU workloads for 24 hours and report CoV. Under 5% is stable. Over 10% means inconsistent performance from neighbor contention.

Disk contention detection

# Extended I/O statistics (watch await and avgqu-sz)
iostat -x 1 10

# 4K random read IOPS (the metric databases depend on)
fio --name=test --size=1G --filename=testfile --bs=4k --rw=randread --iodepth=64 --direct=1

What the numbers mean:

The Contabo SSD line is a documented case: VPSBenchmarks measured ~1,300 IOPS on 4K random reads, which is throttled below what consumer SATA SSDs deliver. Their NVMe line performs much better (33K-46K IOPS) but with higher CPU steal.

What you cannot detect from inside the guest

• KSM status: no guest-side visibility into whether the host deduplicates your memory pages.
• Thin provisioning: no way to tell if your 200GB disk allocation exists as physical storage or as a promise.
• Shared vs dedicated vCPU: lscpu and cat /proc/cpuinfo tell you the CPU model and core count, but not whether those cores are shared with other tenants.
• Node density: no way to count how many VMs share your physical server.

Provider-by-provider overselling evidence

Contabo: the poster child

Contabo's pricing is aggressive: 4 vCPU, 8 GB RAM, 75 GB NVMe for EUR 5.50/month. The "why is my Contabo VPS so slow" question is a genre on hosting forums. The answer is density.

VPSBenchmarks' 24-hour endurance test (June 2024) measured: steal averaging 3.41%, peaking at 5.98%. That is within acceptable range, but community reports tell a different story. A LowEndTalk thread titled "Contabo: New record in CPU steal" documents 70-80% steal on bad nodes. Another thread reports steal averaging 40% and staying there. A third thread warns of problems becoming "unbearable since mid-2024."

The node lottery is real. Contabo's Geekbench 6 single-core scores range from 771 (Cloud VPS 20) to 2,505 (Cloud VPS 30) across different plans per VPSBenchmarks data, reflecting both hardware generation differences and node contention. Contabo will migrate you to a less-loaded node via support ticket, and post-migration performance typically improves.

RackNerd: low steal, high variance

VPSBenchmarks (December 2025) measured RackNerd at 0.07% average steal, 0.11% maximum. Nearly zero. But performance stability scored a D with 7.03% coefficient of variation, meaning benchmark scores fluctuate despite low steal. The instability likely comes from CPU scheduling variance on ColoCrossing infrastructure rather than active resource starvation.

Hetzner: the transparency benchmark

Hetzner is the only budget-adjacent provider that explicitly prices the overselling gap. Their current lineup makes the economics visible:

The 10.1x price multiplier between shared and dedicated at the same core count is the cost of not overselling. BetterStack benchmarked the shared CPX22 at Geekbench 6 single-core scores of 964 and 914 across two runs (5.2% variance), indicating Hetzner does not aggressively oversell even on shared tiers.

BuyVM: "no overselling" with a caveat

BuyVM explicitly markets "absolutely no overselling means no noisy neighbor issues." The caveat: this applies differently by tier. Slices 512 through 2048 ($3.50-$7/month) get "Fair Share" CPU, which is shared but at a lower density than typical budget providers. Only Slices 4096 and above ($15+/month) get truly dedicated pinned cores. The consequence of not overselling: popular plans regularly sell out.

SpeedyPage and DartNode: the anti-overselling plays

SpeedyPage claims "no budget hardware, no overselling" and runs AMD Ryzen 9 7900/7950X/9950X. Their Geekbench 6 single-core hits 1,864 on a 4-core plan, roughly 3x what Vultr's shared plan achieves. Priced at $17.99/month for 4 vCPU / 8 GB.

DartNode's VDS Slices product launched in 2025 with "guaranteed, isolated physical cores and RAM" and "zero steal time." Running Ryzen 9950X dedicated hardware. These are positioned as the premium alternative within the budget market segment.

DigitalOcean and Vultr: the explicit split

Both providers offer clear shared/dedicated tiers. DigitalOcean's documentation states that on shared plans, "a Droplet could receive fractions of hyper-threads instead of dedicated access." Their price gap: shared 2 vCPU at $4/month, dedicated 2 vCPU at $40/month, a 10x multiplier. Vultr follows a similar pattern: shared 1 vCPU at $2.50/month, dedicated 1 vCPU at $28/month.

Why $5/month 4-core VPS exists

Physical hardware is expensive. A 64-core AMD EPYC server costs $10,000-$20,000. Rack space, power, bandwidth, and staff add more. A provider that allocates resources 1:1 must charge enough to cover that hardware cost divided by the number of VMs it can host. A provider that oversells at 4:1 can serve four times as many customers from the same hardware.

The math works because most VPS users leave their CPUs idle 90%+ of the time. A web server handling 1,000 requests per hour uses fractions of a percent of a modern core between requests. An overselling ratio of 3:1 to 5:1 is invisible to these workloads. The problems start when multiple tenants on the same node run sustained CPU workloads simultaneously.

Hetzner's pricing makes the economics explicit. At 4 vCPUs, shared costs EUR 6.49, dedicated costs EUR 85.99. That 4.85x multiplier is the price of guaranteed performance. Contabo offers 4 vCPUs for EUR 5.50 (even cheaper than Hetzner's shared tier), which implies a higher overselling ratio or lower hardware quality.

The "too good to be true" signal: when a provider offers specs that dramatically undercut the market (Contabo's 8 vCPU, 16 GB for ~EUR 13, versus Hetzner's equivalent dedicated at EUR 62.49), the gap is filled by density. You are paying for a larger share of a more crowded room.

When overselling matters and when it doesn't

The rule of thumb: if your workload sustains high CPU utilization for extended periods, overselling will degrade it visibly. If your workload is idle 90% of the time with brief spikes, overselling is invisible. Match the workload to the tier. A $5 shared VPS for a WordPress site is reasonable. A $5 shared VPS for a Minecraft server is not.

FAQ