On a virtual server, top shows a CPU value you won’t see on a physical machine: st, steal time. It’s the share of time your virtual CPU wanted to run but had to wait, because the hypervisor was running something else on the physical CPU. A little steal is a normal part of virtualisation. A lot means your VPS isn’t getting the CPU time it expects.

How it happens

A VPS’s vCPUs are scheduled onto the host’s physical cores by the hypervisor (KVM on VPS.DO plans). When several virtual machines on a host need CPU at the same moment, some must wait. The guest kernel notices that time passed while it wasn’t running, and reports it as steal.

Steal is not caused by anything inside your server. Your own processes using a lot of CPU show up as us/sy, not st.

How to see it

top
%Cpu(s): 42.0 us,  6.0 sy,  0.0 ni, 47.5 id,  0.3 wa,  0.0 hi,  0.2 si,  4.0 st
vmstat 1 10          # 'st' column
mpstat -P ALL 1 5    # per-vCPU %steal (sysstat)
sar -u 1 10          # %steal now
sar -u -f /var/log/sysstat/sa14     # history for the 14th

See top, vmstat and sar.

What’s normal?

Steal Interpretation
0–2% Normal, nothing to do
2–5% occasionally Normal during busy periods on shared infrastructure
5–10% sustained Noticeable for CPU-bound workloads. Monitor and investigate
>10% sustained Your VPS is regularly waiting for CPU. Expect slower performance

Context matters: steal only matters when you need the CPU. 20% steal on an idle server means little. 10% steal while your app is CPU-bound means roughly 10% fewer cycles than expected, plus extra latency.

Symptoms of high steal

  • Response times rise without a matching increase in traffic or us time.
  • Load average goes up while id (idle) and us look moderate.
  • Benchmarks vary a lot between runs or times of day. See CPU benchmarks.
  • Latency-sensitive workloads stutter: game servers (tick lag), real-time trading platforms, VoIP.

What you can do

1. Confirm it’s steal, not your own load. Look at us, sy and wa alongside st. High wa is disk wait, and high us is your own processes. See high CPU usage and load average.

2. Collect evidence over time. Enable sysstat, so you have per-10-minute history (sar -u). Note when steal spikes, and how long it lasts.

3. Contact support with the data (timestamps, sar -u output, mpstat per vCPU). Providers can investigate the host, and may migrate your VPS to a less busy node.

4. Use the CPU you get efficiently.

  • Cache aggressively, so fewer CPU cycles are needed per request. See website speed optimization.
  • Use the right number of workers. Oversubscribing threads on few vCPUs increases scheduling overhead. See PHP-FPM tuning.

5. Choose the right server type for CPU-critical work.

  • More vCPUs give headroom when some cycles are lost. See how many CPU cores you need.
  • A dedicated server has no hypervisor neighbours and no steal, which is the right choice for sustained heavy CPU loads (compilation farms, encoding, busy game servers, high-frequency trading). See USA dedicated servers.

Steal vs other “lost” CPU time

Metric Means
st (steal) Hypervisor ran other work. Outside your control
wa (iowait) Waiting for disk I/O. See I/O wait
si/hi Interrupt handling (network-heavy workloads)
sy Kernel work for your own processes

Container platforms

Inside containers (Docker) you see the host’s or VM’s steal. Containers themselves are limited by cgroup quotas, which show up as throttling, not steal. Check cat /sys/fs/cgroup/cpu.stat for nr_throttled/throttled_usec. See Docker CPU and memory limits.

Quick reference

Task Command
Current steal top (st) / vmstat 1
Per vCPU mpstat -P ALL 1
History sar -u (sysstat)
Rule of thumb <5% fine, >10% sustained = investigate

Related: KVM vs OpenVZ vs LXC and CPU info.

  • VPS Guides
  • Performance
  • Linux