Load Average and CPU Steal on Virtualized Hosts

Load average is the most quoted and least understood number in Linux. Combine it with the steal column unique to virtualized hosts, and you have a reliable way to tell whether your VPS is genuinely overloaded or just sharing a busy physical node. Confusing the two leads to buying the wrong resource or blaming the wrong layer.

What load average actually counts

The load average is a moving average of the number of tasks that are either running on a CPU or want to run, computed over one, five, and fifteen minutes. On an idle box it sits near zero. On a box that has more runnable work than cores, it climbs. The classic rule is that load below the core count is comfortable and load above it means saturation.

For a virtual machine the caveat is big: the kernel counts tasks delayed waiting for the hypervisor to schedule them, so steal inflates load even when your own processes are well behaved. High load on a virtualized host deserves a second look before you blame your app.

Steal is the tell

The steal column in top and mpstat reports how many CPU cycles the kernel wanted but a hypervisor granted to a neighbour instead. It only exists on virtualized hosts, Netbay included. When steal rises, your vCPUs are physically available but not physically scheduled, and no tuning of your application fixes that.

mpstat -P ALL 2 5
# the %steal column is the one you watch
top -n 1 -b | grep Cpu

If steal is consistently above five to ten percent at the same time the load average is high, you are competing for the physical core. This is different from load caused by your own CPU-bound processes, and it explains why adding cores to your plan does not always help in the moment.

Reading the two together

• Low load, low steal: everything is fine; a slow app is latency or I/O, not CPU.
• High load, low steal: your own processes are genuinely CPU-starved; more cores help.
• High load, high steal: the physical node is busy; other tenants are competing for cycles.
• Low load, high steal: another tenant is bursting hard; your experience degrades even though you are idle.

Anchoring load to your vCPU count

The classic rule compares the load average to the number of logical CPUs. On a three-vCPU plan, a load average of 3 means the tasks are stretching the available cores; a load of 1 on the same box is comfortable headroom. Read load against nproc, not against an absolute number, and only after subtracting obvious steal.

nproc
# load is in the middle columns of uptime; compare to nproc
uptime

A load that sits at roughly your vCPU count with notable steal is a crowded node, while the same load with zero steal is pure demand you can satisfy with scaling or more cores. The two cases have opposite fixes, which is exactly why the steal column is indispensable on a VPS.

A quick script for the trend

Steal is intermittent, so sample it over time rather than once. This loop logs load and steal every five seconds and keeps the record in a single file:

while true; do
  printf "%s " "$(date +%H:%M:%S)"
  uptime
  mpstat -P ALL 1 1 2>/dev/null | awk 'NR==4 {print "steal="$13}'
  sleep 5
done > /var/log/steal.log 2>&1

Review the log after a slow period. If steal spikes coincide with your slow minutes, the cause is host contention, not your code, and the realistic options are fewer but clearer.

What you can and cannot fix

• Your own CPU-bound load: add cores or optimise the code.
• Memory pressure: add RAM or fix the leak.
• Steal from a busy node: you cannot tune it away. Test whether a different sized instance on a quieter slice behaves better, and time your heavy jobs away from other tenants.

Takeaway

Stop reading load average in isolation. Pair it with the steal column, which exists precisely because a VPS shares silicon. When the two tell you it is host contention, plan for it rather than chasing ghosts in your code. Netbay provisions Linux and Windows VPS quickly at netbayhosts.in; spin one up to reproduce your exact numbers.