VPS Overprovisioning: How to Detect and Avoid It

Overprovisioning — also called overcommitment — means a hosting provider sells more virtual resources than the physical host owns. A machine with 32 CPU cores might carry not 32 but 100 or more vCPUs spread across many customer servers. As long as not everyone loads the CPU at once, the maths works out. But the moment several neighbours compute simultaneously, they contend for the same physical cores — and your VPS waits.

What overprovisioning actually means

Providers overbook for economic reasons: most VPS sit idle most of the time, so the same hardware can be sold several times over. What matters is the ratio. Moderate overcommitment is barely noticeable; an aggressive one means the promised resources are regularly unavailable under load. The opposite model is firmly reserved or dedicated resources: what you are promised is actually yours — at all times.

vCPU vs RAM overcommit

It is not only the CPU that gets overbooked. Four resources are affected, with very different consequences:

• vCPU overcommit: more assigned vCPUs than physical threads. The hypervisor time-slices compute — under contention your VM waits for free cycles.
• RAM overcommit: more promised memory than physically installed, papered over with ballooning, KSM or swapping. When real RAM runs out, data spills to disk — orders of magnitude slower.
• Storage overcommit (thin provisioning): more promised space than exists. Harmless until every tenant fills it at once.
• Network overcommit: one uplink shared by many. Only felt under load, as a drop in throughput and latency.

Why overprovisioning kills performance

The tricky part about overprovisioning is that benchmarks look fine when the host is idle. Performance only collapses when the 'noisy neighbours' generate load at the same time — and it does so unpredictably. For a database that means fluctuating query times, for a shop higher response times at peak, for a build server longer pipelines. RAM overcommit hurts most: once the system swaps, performance does not degrade linearly but falls off a cliff.

Detecting it: CPU steal time

The most telling indicator is CPU steal time (the `%st` metric). It measures the share of time your virtual CPU wanted to run but had to wait because the hypervisor gave the physical cores to other VMs. You can see it in `top`, `vmstat`, or in more detail with `mpstat -P ALL 1`. A persistently elevated value is the clearest sign of an overbooked host.

• Swap activity: high `si`/`so` values in `vmstat` point to RAM pressure or RAM overcommit.
• Load average persistently above your vCPU count despite modest load of your own.
• The same benchmark giving markedly different results at different times of day.