High CPU Steal on Your VPS? Measure It and Fix the Root Cause

CPU steal is the percentage of time your virtual machine wanted to run but the hypervisor gave the physical CPU core to another tenant. On shared VPS infrastructure it is the most common cause of “the server feels slow but nothing is using the CPU” complaints. Unlike memory pressure or a misconfigured application, steal is invisible in htop unless you know which column to read, and it cannot be fixed with more RAM or a faster framework. This guide explains how to measure steal reliably, what the numbers mean, and what actually reduces it.

How CPU steal shows up in your metrics

On Linux, the kernel accounts steal time in the st column of top, vmstat, and mpstat. It appears whenever the hypervisor schedules a different virtual machine on the physical core your vCPU depends on. The telltale signature is high st with low us and sy: the CPU is not busy doing your work — it simply was not given time to do it.

Tool	Command	What to look at
top / htop	top -d 2	st column; sustained >5% while load is high
vmstat	vmstat 1	st column in the CPU section
mpstat	mpstat -P ALL 1	%steal per vCPU
sar	sar -u 1 10	%steal history via sysstat

What the numbers actually mean

• 0–2% sustained: normal on shared hosts. Ignore single spikes.
• 2–5% sustained: worth watching; expect occasional latency spikes during host-wide peaks.
• 5–10% sustained: your application is measurably slower. Investigate patterns (time of day, host-wide cron jobs).
• Over 10% sustained: the host is oversubscribed. This explains real user-facing slowdowns and is a legitimate reason to move.

Steal, iowait, or just a slow app?

Before blaming the provider, rule out the other two suspects:

• iowait high and st low: storage is the bottleneck, not the CPU scheduler.
• us + sy near 100% with st low: your code is genuinely CPU-bound. Tune the application or add vCPUs.
• st high while us/sy are low: the classic steal signature. No amount of application tuning fixes this.

Also compare load average against your vCPU count. Load persistently above the vCPU count means the VM is waiting for CPU time — which is exactly the condition steal measures.

Because steal varies with host load, a single reading is not enough. Log %steal over a week with a lightweight loop — for example mpstat -P ALL 10 >> /var/log/steal.log under cron — then look at the weekly average and the 95th percentile. A host that is fine at noon and saturated at 8 p.m. still hurts you if that is when your traffic peaks. Providers with dedicated CPU cores publish that guarantee in their plan specs; shared hosts publish nothing, which is exactly why the measurement is on you.

What actually reduces CPU steal

Steal is a host-level property, so the fixes are about placement and plan design, not kernel parameters:

1. Move heavy jobs off peak hours. Cron backups, log aggregation, and database maintenance at 02:00 hit a quieter host. Even on an oversubscribed node, off-peak steal is usually far lower.
2. Right-size the plan. A bursty 1-vCPU instance that peaks at 100% every few minutes suffers more from steal than a 2-vCPU plan with headroom, because steal hurts most when a vCPU is saturated.
3. Ask for a different host. Many providers migrate you to another node on request. If steal follows you, the provider’s overall oversubscription is the problem.
4. Move to a dedicated-CPU or dedicated-core plan. These guarantee physical cores and eliminate steal almost entirely — the definitive fix for latency-sensitive workloads.
5. Benchmark before you commit. Run the same workload on a trial instance on different hosts and compare st and request latency before signing up long-term.

Benchmarking steal before you buy

A quick, repeatable test: run sysbench cpu --threads=4 --time=60 run (or openssl speed) three times on a trial instance, capture mpstat -P ALL 1 during each run, and average the %steal column. Repeat at different times of day if you can. If average steal stays above 5% during a trivial CPU benchmark, the host is already saturated — it will only get worse under real traffic. This is also the moment to compare providers on our comparison table, because CPU allocation model, storage type, and guaranteed resources matter as much as the sticker price.

When steal is not the problem

If the metrics say steal is low but the site is slow, look elsewhere: swap thrash (the si/so columns of vmstat), network latency, TLS handshake overhead, or a database query missing an index. A common and expensive mistake is blaming the host for what is actually a 5 MB unindexed table scan. Measure first, then decide.

The bottom line

CPU steal is a real, measurable cost of shared hosting, and the fix is placement and plan design rather than configuration heroics. When you evaluate plans, see the full specs and pricing side by side, and run the benchmark above on any candidate before you pay. If your workload needs consistent CPU, a dedicated-core plan removes the variable entirely.