Turkey (Turkish)
Germany (German)
Worldwide (English)
Linux kernel documentation defines steal as involuntary guest wait; the sar manual defines %steal as time a virtual CPU waits while the hypervisor services another virtual processor.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Measure %steal on Linux VPS using top, mpstat, sar and /proc/stat; distinguish CPU contention from application bottlenecks.
Linux kernel documentation defines steal as involuntary guest wait; the sar manual defines %steal as time a virtual CPU waits while the hypervisor services another virtual processor.
Steal time is a virtualization-scheduler signal and does not have the same meaning on bare metal.
The guest may want to run while the hypervisor gives physical CPU time to another VM. This can appear as %steal. Application CPU may look low while request latency rises.
Not every slowdown is steal. Disk iowait, memory pressure, swap, network loss, DB locks, worker queues and DNS can feel similar. Treat steal as one diagnostic signal.
In top, `st` is a quick check. `mpstat -P ALL 1` shows per-CPU steal and `sar -u 1 60` gives a time series. `/proc/stat` exposes the raw counter.
topmpstat -P ALL 1 20sar -u 1 60grep '^cpu ' /proc/statOne one-second spike is not enough. Collect 5-15 minute samples under the same workload at different times. Repeated increases during busy periods strengthen the host-contention hypothesis.
Some providers publish practical steal ranges, but there is no universal threshold that fits every workload. Latency-sensitive applications can notice smaller values.
A cgroup/provider CPU quota can throttle a guest after it consumes its allowance; steal is involuntary waiting caused by hypervisor scheduling. Symptoms can look similar but fixes differ.
Container VPS may expose throttling through cgroup metrics, while full VMs often emphasize steal and guest scheduler metrics.
Record a repeatable CPU test, application response time and steal together. If benchmark runtime and application latency degrade as steal rises under the same workload, host contention becomes more likely.
sysbench cpu --threads=1 --time=30 runsysbench cpu --threads=$(nproc) --time=30 runSend timestamp/timezone, mpstat or sar output, VM CPU model/vCPU count, workload description and application-response evidence. Measurable data is far more actionable than simply saying the server is slow.
| Metric | If high, consider |
|---|---|
| %steal | Hypervisor scheduling/contention |
| %iowait | Storage wait |
| High load, low CPU | I/O or blocked tasks |
| Swap rising | Memory pressure |
Do not buy based on one benchmark, port label or CPU brand. Repeat tests at different times, avoid destructive storage tests on production data, and verify provider resource/fair-use policies in writing.
Lower and stable is better; small transient values can occur. Interpret them together with workload latency.
It can reduce demand, but true host contention requires provider-side capacity or placement changes.
Share your software stack, concurrency, storage/database load and target region; size the server around the real bottleneck rather than RAM/core labels alone.