VPS CPU steal: how to check it and investigate a slow server

Check a short sample without changing the server

Run these commands inside the affected Linux VPS. They only read system information. vmstat comes from procps; use your distribution's package instructions if it is not installed.

The first vmstat CPU report contains averages since boot. Read the following reports for one-second intervals. Keep the column headings: versions can include an extra guest-time column, so st is not always the last number.

date -u
getconf _NPROCESSORS_ONLN
LC_ALL=C vmstat 1 6

vmstat manual and CPU column definitions | Linux /proc CPU accounting

Read st alongside the other CPU columns

st is reported as a percentage of CPU time. Linux records steal as time spent in involuntary wait in a virtualized environment; it is separate from guest user/system work, idle time and I/O-wait accounting. The r column in vmstat reports runnable processes. Look at these signals during the same period as a slow request or growing work queue.

If us and sy are busy but st stays low, investigate the processes using your assigned CPUs. If st rises repeatedly while a CPU-bound application waits, ask the provider to investigate host scheduling. Steal time shows that the guest lost CPU scheduling time, but it does not identify which neighbouring VM, host policy or physical-CPU condition caused it. A storage or network delay needs a different investigation.

Linux /proc/stat steal-time definition

Check whether one virtual CPU is affected more than the average

A guest-wide average can hide an uneven problem across vCPUs. If the sysstat tools are installed, mpstat can report each processor separately and includes a %steal column. Compare per-vCPU samples during the same slowdown rather than treating one boot-time average as current evidence.

Do not install diagnostics in the middle of a production incident unless that change is appropriate for the server. If mpstat is already available, the command below is read-only; otherwise the vmstat sample above is enough to start the investigation.

LC_ALL=C mpstat -P ALL 1 5

mpstat per-processor and %steal fields

Record the slowdown, not just a screenshot

A five-second check is a starting point. Collect longer samples during both normal and slow periods and compare them with request durations, database timings or job completion times. An average can hide short bursts or one heavily affected virtual CPU.

For a support request, include UTC timestamps, the number of vCPUs, the command and output headings, and a brief description of what became slow. Remove customer data, tokens and private paths from any logs you attach.

• When did the slowdown start and stop?
• Was the same workload fast at another time?
• Were backup jobs, imports or builds running?
• Does the latency rise when the steal percentage rises?

Do not assume a larger plan is the fix

There is no single steal percentage that diagnoses every workload. A short spike with no noticeable effect is different from persistent waits during a time-sensitive task. A guest reporting zero steal is not proof that every host resource is unconstrained.

First rule out your own CPU-heavy jobs, application locks, memory pressure and storage waits. More vCPUs can help parallel work that needs them; they will not fix every single-threaded task or a remote API timeout. Ask the provider what a resize or move would change before paying for it.

Estimate the resources your application needs | Investigate VPS disk latency

Choose hosting for the workload you actually run

Compare the CPU allocation, memory, storage and management responsibilities of the plans you are considering. Shared vCPU does not mean dedicated physical cores. A dedicated server may suit a workload that requires its own physical host, but it is a separate product and cost.

DotMoose VPS plans are self-managed. Send us your workload and the measurements above if you need help comparing a VPS with a dedicated-server quote.

VPS hosting specifications and prices | Dedicated-server enquiries