CPU Steal Time: Why Your VPS Lags at Peak Hours

Here is a maddening pattern: your VPS runs a CS 1.6 server that is smooth at 3pm and stutters every evening at peak, even though your own CPU usage has not changed. The cause is almost always CPU steal time — the hypervisor is giving the physical core your vCPU maps to another tenant, and your server simply does not get to run when it needs to. You cannot cvar your way out of it; it is the host oversubscribing hardware. But you can prove it, and proof is what gets you a refund or a migration.

1. What steal time actually is

Your "vCPU" is a share of a real physical core scheduled by the host's hypervisor. When another VM on the same physical core is running, your vCPU is ready to run but is not being scheduled — that waiting time is steal. From inside your guest it looks like the CPU vanished: your process is runnable, nothing is using your CPU, yet work is not getting done. On an honest, non-oversold host, steal is essentially zero. On an oversold node it climbs exactly when neighbours get busy — evenings and weekends — which is why your lag tracks the clock, not your player count.

2. Read %st in top

Run top and look at the CPU summary line:

%Cpu(s):  12.3 us,  4.1 sy,  0.0 ni, 78.2 id,  0.0 wa,  0.0 hi,  0.4 si,  5.0 st

That trailing st is steal, as a percentage. 5.0 st means 5% of wall-clock time your vCPU wanted to run and could not because the host gave the core to someone else. A few tenths is noise; sustained single or double digits is a problem, and it directly translates to a single-threaded game server missing its frame deadlines.

3. Confirm with vmstat and mpstat

vmstat shows steal in its own column so you can watch it over time:

vmstat 1
# procs -----------cpu-----------
#  r  b   us  sy  id  wa  st
#  1  0    9   3  80   0   8

The final st column is steal. For per-core detail — useful because a pinned server only cares about its core — use:

mpstat -P ALL 1
# watch the %steal column per CPU

4. Correlate steal with the lag

Do not guess — log steal through a peak so you have evidence. Record it over an evening:

sar -u 1 >> /var/log/steal-watch.log   # %steal is in the output
# or a crude sampler:
while true; do date; vmstat 1 2 | tail -1; sleep 60; done

If the st figure spikes at exactly the times players complain, you have your answer. Cross-check that your own core is not simply saturated — if %us is near 100% too, that is a CPU-speed problem, not steal. Steal is specifically idle-you, busy-someone-else.

5. What you can actually do

Steal is the host's doing, so your options are about the host, not the guest:

• Open a ticket with the evidence. A reputable host will migrate your VM to a less-loaded node when you show sustained steal. Many oversold budget hosts will not — which tells you what you bought.
• Buy a dedicated-vCPU plan. Some providers sell plans with guaranteed/pinned physical cores (often labelled "dedicated CPU"). Steal on those is near zero by contract.
• Move to a real box. A dedicated server has no hypervisor and therefore no steal, ever. For a competitive server it is the honest fix.
• Migrate away. If a host consistently shows double-digit steal at peak, no cvar or upgrade tier fixes an oversold node — change provider. See cheap hosting vs a real VPS.

Common mistakes

• Blaming your config for peak-hour lag — if steal spikes at peak and your CPU% did not, the config is innocent. Read %st.
• Confusing steal with your own load — high %us is you needing a faster core; high %st is the host not scheduling you.
• Confusing steal with %wa — wa is I/O wait (disk), a different problem entirely.
• Accepting "it's normal" — sustained double-digit steal is not normal; it is oversubscription. Get evidence and escalate or leave.

Verification

Leave a sampler running across a full peak window and read the log the next day. A healthy result is st hovering near 0.0 even while the box is busy with your own work; an unhealthy one is st climbing into the high single or double digits precisely when the server lags. If it is the latter, attach the log to a support ticket — concrete vmstat/sar output showing sustained steal is far harder for a host to wave away than "my server feels laggy." If they will not fix it, you now know to size your next move toward a dedicated-vCPU plan or a real machine.