{"id":888,"date":"2026-08-14T23:15:27","date_gmt":"2026-08-14T23:15:27","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=888"},"modified":"2026-09-24T22:03:04","modified_gmt":"2026-09-24T22:03:04","slug":"cpu-steal-vps-performance","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/cpu-steal-vps-performance\/","title":{"rendered":"Measuring Sustained CPU Steal on a VPS and Choosing the Right Fix"},"content":{"rendered":"\n

CPU steal is the percentage of time your virtual machine wanted to run but the hypervisor gave the physical CPU core to another tenant. On shared VPS infrastructure it is the most common cause of “the server feels slow but nothing is using the CPU” complaints. Unlike memory pressure or a misconfigured application, steal is invisible in htop<\/code> unless you know which column to read, and it cannot be fixed with more RAM or a faster framework. This guide explains how to measure steal reliably, what the numbers mean, and what actually reduces it.<\/p>\n\n\n\n

How CPU steal shows up in your metrics<\/h2>\n\n\n\n

On Linux, the kernel accounts steal time in the st<\/code> column of top<\/code>, vmstat<\/code>, and mpstat<\/code>. It appears whenever the hypervisor schedules a different virtual machine on the physical core your vCPU depends on. The telltale signature is high st<\/code> with low us<\/code> and sy<\/code>: the CPU is not busy doing your work \u2014 it simply was not given time to do it.<\/p>\n\n\n\n

Tool<\/th>Command<\/th>What to look at<\/th><\/tr><\/thead>
top \/ htop<\/td>top -d 2<\/code><\/td>st<\/code> column; sustained >5% while load is high<\/td><\/tr>
vmstat<\/td>vmstat 1<\/code><\/td>second st<\/code> column (percentage of total CPU)<\/td><\/tr>
mpstat<\/td>mpstat -P ALL 1<\/code><\/td>per-vCPU %steal<\/code>; one hot vCPU points to a single noisy neighbor<\/td><\/tr>
sar<\/td>sar -u 1 5<\/code><\/td>%steal<\/code> historical trend if sysstat is installed<\/td><\/tr>
pressure<\/td>cat \/proc\/pressure\/cpu<\/code><\/td>some total= value is real stall, not just steal<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A single reading proves nothing. Steal of 15% for two seconds during a backup window is normal; steal of 8% sustained for twenty minutes across every sample is a capacity problem. Sample with sar<\/code> or a loop, and compare against the same hours on the previous day before concluding anything.<\/p>\n\n\n\n

# 60 samples, print steal only\nfor i in $(seq 60); do\n  mpstat 1 1 | awk '\/Average\/ {print $3\"% us  \"$6\"% steal\"}'\ndone<\/code><\/pre>\n\n\n\n
Separating steal from your own CPU use<\/h2>\n\n\n\n
The critical distinction is whether your workload is the cause. If us<\/code> plus sy<\/code> is low and st<\/code> is high, the hypervisor is starving you. If us<\/code> is high and st<\/code> is low, your own processes are simply busy and the fix is at the application layer. A workload that saturates its own vCPUs can also trigger more steal because the hypervisor is more likely to preempt a busy guest.<\/p>\n\n\n\n
Run this comparison on a schedule so you have a baseline before the complaint arrives:<\/p>\n\n\n\n
vmstat 1 10 | tail -n +2 | awk '{print \"us=\"$13\" sy=\"$14\" id=\"$15\" wa=\"$16\" st=\"$17}'<\/code><\/pre>\n\n\n\n
What actually reduces steal<\/h2>\n\n\n\n