US East introductory rate: KVM VPS and CDN origin VPS in our Ashburn region are 50% off, applied automatically at checkout. Explore US East →Monthly and longer billing periods. New orders until 31 October 2026.

← Back to blog

CPU Steal Time: When a VPS Has Outgrown Shared Hardware

Maria Ilinca Bostan

CPU steal time is the share of time a virtual CPU was ready to run but the hypervisor gave the physical CPU to something else. Linux reports it inside the guest as st, next to user, system and idle time. On a bare metal server there is no hypervisor below your operating system, so there is nothing to steal from and steal stays at zero.

If your service got slower without a code change, check steal before you spend a week profiling.

What is steal time, and where does it come from

A VPS is a set of virtual CPUs scheduled by a hypervisor, like every VPS anywhere. Under KVM each vCPU runs as a thread on the host, and the host scheduler decides which threads get a physical core at each moment. When more vCPUs want to run than there are hardware threads free, some wait. The time your vCPU spent waiting while it had work is steal.

KVM passes a steal counter to the guest kernel, so the figure Linux prints is the hypervisor's own accounting. Two details matter. Steal only accrues while your vCPU has something to run, so an idle VPS shows zero steal even on a crowded host. And it only counts waiting for a core: a noisy neighbour thrashing the shared cache or memory bus slows you down without adding any steal.

Where to read st in top, vmstat, sar and Prometheus

Every standard Linux tool reads the same kernel counter. Pick one by time span: now, the last minute, or the last week.

  • top: the summary line starting %Cpu(s) ends with st, the percentage stolen across all vCPUs. Press 1 to split it per vCPU, because one starved vCPU out of eight barely moves the average.
  • vmstat: give it an interval, such as vmstat 5, and read the st column. Ignore the first line, which averages everything since boot. The same output shows the run queue (r), iowait (wa) and swapping (si and so).
  • mpstat: from the sysstat package. It prints %steal as its own column and can list every processor separately.
  • sar: also from sysstat, and the one that matters. With its collector enabled it samples every ten minutes by default and keeps daily files, so you can look back at last Tuesday. Some distributions install the collector switched off, so enable it now.
  • /proc/stat: the raw source. The eighth number on each cpu line is steal, in clock ticks since boot.
  • Prometheus node exporter: steal is the steal mode of node_cpu_seconds_total. Graph rate(node_cpu_seconds_total{mode="steal"}[5m]) next to your latency panels.

How much steal time is too much

There is no universal threshold. These are rules of thumb, not guarantees:

  • Occasional low single digit steal is normal on shared hardware.
  • Sustained steal of several percent while your own workload is busy is what users start to feel.
  • Spikes that line up with your latency complaints are the evidence to keep.

Remember that st is a share of all time, idle included. Seven percent steal on a guest that wanted the CPU half the time means roughly one in seven of its turns went to someone else.

Why a 20 ms request stops taking 20 ms

Take a request that needs 20 ms of CPU. If 10 percent of the vCPU's runnable time is stolen and the loss were spread evenly, the request would take about 22 ms and nobody would notice. Steal is not spread evenly. It arrives in slices of a few milliseconds when the host runs another guest instead of you, and a request in flight at that moment stops, along with everything queued behind it. The average barely moves while the slowest 1 percent gets much slower, so steal shows up first in p99 latency and timeouts.

Rule out the look alikes first

Several problems feel exactly like steal from the outside. Check these first, because the fixes differ.

SymptomMetric that shows itFix
CPU flat out, work queues upus and sy high, r in vmstat above your vCPU countProfile and optimise the workload, or add vCPUs
Slow responses while the CPU looks idlewa high in top or vmstatCut heavy reads and writes, add caching, use faster NVMe storage
Everything slows, then the disk gets busysi and so above zero, little available memory in freeAdd RAM, cap caches and worker counts
Transfers plateau at the same speedThroughput flat at a fixed ceiling, CPU calmCheck the port. Our VPS plans are shaped at 100 to 300 Mbps by plan, dedicated servers get a guaranteed 1 Gbps
Latency spikes at certain hours, CPU busy but not saturatedst of several percent in sar while us is highMeasure, resize, talk to the provider, then move to bare metal

If two rows match, fix your own saturation first. A guest running flat out turns any host contention into steal, which hides how much is really the neighbours.

What are the performance differences between dedicated CPU and shared vCPU?

A dedicated server gives you the same compute every second. A shared vCPU gives you whatever the busy neighbours leave. It shows in three places.

Consistency and tail latency

On bare metal no host scheduler sits between your threads and the cores, so steal is zero and p99 latency reflects your code, data and load. On any VPS the slowest requests also carry the host's contention. Plans with pinned vCPUs remove most steal, but those guests still share the host's cache and memory bandwidth.

Cache and memory bandwidth are not shared

Guests on one host share the processor's L3 cache and memory controllers, and a neighbour streaming a large dataset can push your working set out of cache. On a dedicated server the whole L3 is yours: 128 MB on a Single EPYC 9254, 2 × 35 MB on a Dual Xeon E5 2690 v4. The EPYC 9004 platform has twelve DDR5 channels per socket, and whatever bandwidth the populated channels deliver serves only you.

Capacity planning you can trust

A load test on a dedicated server still holds next month, because nothing else on the machine changes. On a VPS the same test at 4 in the morning and 8 in the evening can disagree. Physical cores also make costs easy to compare: €8.89 per core per month on the Dual Xeon E5 2690 v4, €20.21 on the Single EPYC 9254, as our cost per core breakdown shows.

When to move from a VPS to a dedicated server

Work through these in order. Each step costs less than the next.

  1. Measure for a week. Let sar collect through your busiest days so steal per vCPU, your own CPU use and p99 latency sit on one timeline.
  2. Resize the VPS. If steal is moderate and your own CPU use is high, more vCPUs give you slack, so a parked vCPU costs less. On our KVM VPS range an upgrade is a resize in the panel, not a rebuild, from Ion at 1 vCPU to Titan at 8 vCPU and 32 GB.
  3. Talk to the provider with your sar data. Timestamps, per vCPU steal and the matching latency give them something to check on the host. A screenshot of top does not.
  4. Move to bare metal when the workload needs consistent per core performance. Latency bound APIs, database servers with tight query budgets and trading bots belong where nobody else's load can reach.

Which dedicated server fits a latency bound service

For a service that left a VPS because of steal, per core speed matters more than core count.

  • Single EPYC 9254: 24 Zen 4 cores and 48 threads, 2.9 GHz base and 4.15 GHz boost, 128 MB of L3, 128 GB of DDR5 ECC and 2 × 1 TB NVMe for €485 a month. One socket means no NUMA layout to tune, as our single vs dual socket guide explains. Built to order, about 14 days.
  • Dual Xeon E5 2690 v4 for a tighter budget: 28 cores and 56 threads, 3.5 GHz boost, 2 × 35 MB of L3, 128 GB of DDR4 ECC and a 240 GB SSD for €249 a month, delivered in about 45 minutes. With two sockets, pin the latency sensitive process and its memory to one socket with numactl.

Your own hypervisor brings steal back, on your terms

Split the server into VMs with Proxmox VE and they can steal from each other when their busy vCPUs outnumber your threads. But you set the ratio: never oversubscribe the latency bound VM and let batch jobs share the rest. Our guide on how many VMs to run on a dedicated server covers that choice.

Questions we get

Why does top show 0.0 st when my service is slow?

Either the vCPU was idle when you looked, or the cause is something steal does not measure: your own saturation, iowait, swapping, a network ceiling, or a neighbour competing for cache. Check sar for the hours users complained about.

Will adding vCPUs fix high steal time?

It helps when your own load is high, because work can move to a vCPU that is running while another waits. It does not remove host contention. If steal stays at several percent after a resize, take the data to the provider and plan the move.

Is there steal time on a dedicated server?

Not for an operating system installed directly on the hardware. With no hypervisor underneath, st reads zero. VMs you create on it can show steal, but only from each other, at a ratio you choose.

Next step: give the service cores of its own

If a week of sar data shows steal tracking your latency, compare the EPYC 9254 configuration with our full dedicated server range. Every server includes full root access, a guaranteed 1 Gbps unmetered port, 1 Tbps always on DDoS protection (L3/L4) and no setup fee.

Billed monthly · no setup fee

Deploy your first server now.

No contracts, no minimum term. Intel Xeon builds carry a delivery estimate of under an hour; AMD EPYC builds are made to order. Every configuration has full root, ECC memory and a guaranteed 1 Gbps unmetered port.

$ curl https://my.voxa.host/api/v1/products -H "Authorization: Bearer fbk_…"

Dedicated billed monthly · No setup fee · Full root on every server

Included with every dedicated server
IPv4 address
One included
Unmetered port
1 Gbps guaranteed
DDoS protection
1 Tbps · L3/L4
Root access
Included
Setup fee
€0.00
Minimum term
None