What is CPU steal time (%st)?

Definition#

Steal time is the percentage of time a virtual CPU had work ready to run but could not run it, because the hypervisor had scheduled the underlying physical CPU to something else. It is time your virtual machine spent involuntarily waiting for a physical core: not idle (there was work to do), not blocked on disk or network (the task was runnable), simply not given hardware to run on during those moments.

The metric exists only in virtualized environments. On physical hardware, a runnable task waits only for other tasks on the same machine; under virtualization, the machine itself can be made to wait, and steal time is how the guest kernel accounts for it.

Where it comes from#

A hypervisor multiplexes virtual CPUs onto physical cores the same way an operating system multiplexes processes onto CPUs: vCPUs are, to the host, schedulable threads. When the sum of vCPUs across all guests exceeds the physical cores available, or simply when several guests demand CPU at the same instant, runnable vCPUs queue. The host informs each guest (through paravirtualized clock interfaces) how long its vCPUs sat in that queue, and the guest kernel reports it as steal.

Two properties follow directly from this mechanism:

• Steal accumulates only under demand. A vCPU that asks for nothing is never made to wait, so an idle guest shows near-zero steal regardless of how contended the host is. Steal is therefore meaningful only when measured while your workload is actually running.
• Steal is entirely a host-side phenomenon. Nothing inside the guest, process priorities, nice, kernel or scheduler tuning, changes it, because the waiting happens below the guest's kernel. A guest can measure steal; it cannot influence it.

A related, deliberate case: burstable or credit-based instance types (common at large clouds) enforce their CPU caps through the same mechanism, when the credit is spent, the hypervisor withholds cycles, and the guest sees it as steal. There, high steal is the product working as designed rather than contention.

How to observe it#

The guest kernel exposes cumulative steal ticks as the eighth field of each CPU line in /proc/stat; the familiar tools present it as a percentage:

• top / htop: the st value at the end of the CPU summary line (%Cpu(s): ... 1.7 st).
• vmstat 1: the st column, sampled per second.
• sar -u (sysstat): %steal, with history, which matters because steal is often periodic (a neighbor's nightly job) and a single glance misses the pattern.
• mpstat -P ALL shows it per vCPU.

Single samples mislead in both directions; judge steal by its sustained value under your own load, ideally from a time series covering at least a day.

Interpreting the numbers#

• 0%: your vCPUs get a physical core the moment they ask. The expected state on dedicated or lightly shared hosts.
• Transient low single digits: ordinary scheduling coincidence, two guests occasionally wanting the same core at the same tick. Imperceptible for almost all workloads.
• Sustained 5 to 10%: measurable. Throughput drops and, often more noticeable, latency becomes jittery, individual requests stall for scheduling gaps that the application cannot see or log, so response times develop an unexplained tail.
• Sustained above 10 to 20%: severe contention. Everything stretches, and interactive workloads feel it constantly.

A useful first-order model: sustained steal of s stretches CPU-bound wall-clock time by roughly a factor of 1/(1 − s), at 20% steal, a job that needs 60 CPU-seconds occupies about 75 seconds of real time. The model is approximate (it ignores burstiness and cache effects, which usually make the felt impact worse than the arithmetic), but it sets the scale: steal is not cosmetic once it is sustained.

Steal also inflates the load average: tasks that are runnable-but-waiting count toward load, so a contended guest can show climbing load with modest %us, a signature worth recognizing.

Distinguishing steal from your own saturation#

The CPU summary line separates the cases cleanly:

• High us/sy, near-zero st: the machine is busy with your work. The remedy is inside the guest, profile, optimize, or add cores.
• Meaningful st while us+sy cannot reach the ceiling: the machine is being made to wait. The remedy is structural, nothing inside the guest will change it.
• High wa is a third, unrelated axis: waiting on I/O, not on CPU at all.

What determines how much steal you see#

On any shared platform, steal is a function of decisions made on the host: the overcommit ratio (total vCPUs sold per physical core), the demand patterns of co-tenants (steal from neighbors is bursty and time-of-day shaped), and the hypervisor's scheduling policy (shares, weights, caps). At one extreme, hosts with pinned or reserved cores produce steal that is zero by construction; at the other, heavily oversold hosts produce chronic double-digit steal. Between providers and products, this ratio, not the advertised core count, is the variable that decides how much of a "4 vCPU" machine you actually get during busy hours.

What a tenant can do#

1. Measure properly: a sar or monitoring-agent time series of %steal under real load, over days, is objective evidence, and distinguishes chronic overcommit from a transient neighbor.
2. Re-check your own side: confirm the slowness correlates with st and not with us/sy (your code) or wa (your disk I/O).
3. Structural remedies: since steal cannot be tuned away from inside the guest, persistent high steal is resolved by moving the workload, to a host or product where CPU is dedicated or pinned, or by accepting the trade-off consciously where the workload tolerates it (batch jobs care little; latency-sensitive services care a lot).

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• a sar or vmstat sample of %st under real load, with the timeframe it covers.

Related questions#

• "What does st mean in top?"
• "What is a normal CPU steal time value?"
• "Why is my VPS slow with low CPU usage but high steal?"
• "Can I reduce steal time from inside my server?"
• "How does CPU overcommit cause steal time?"
• "Why does my load average rise when steal time is high?"