Context
A virtual Linux server can be slow because its guest has more runnable work than it can execute, because the hypervisor is not scheduling it promptly, or because tasks are waiting on another resource. CPU steal time helps investigate host scheduling, but it must be read alongside the run queue, process behavior, and provider evidence.
Understand what steal time represents
Steal time reports virtual CPU time that the guest wanted but the hypervisor did not provide, where the platform exposes that accounting. Linux tools can display it as st or %steal. The metric's availability and interpretation depend on the virtualization environment.
Do not equate a high load average with high CPU utilization. Linux load also includes certain uninterruptible waits. A storage problem can produce a large load average while processors are not busy executing application work.
Capture the incident as an interval
Collect synchronized application latency, throughput, runnable tasks, per-CPU utilization, steal time, I/O wait, memory pressure, and major workload events. Read-only tools such as vmstat, mpstat where installed, and process-level diagnostics can provide complementary views.
Use several samples rather than the first cumulative line from a tool. Record vCPU count, VM type, host or placement context where accessible, and recent changes. A single screenshot after the workload recovers cannot establish what constrained it during the incident.
Normalize application metrics by accepted work. A server processing fewer requests can report less guest CPU while users wait longer. That is why latency, queue depth, and completion count belong beside utilization.
Separate three common patterns
First, high runnable demand with low steal can indicate ordinary guest CPU contention. Profile expensive code, inspect worker count, and assess whether the VM has enough sustained capacity.
Second, steal increases during latency degradation while the workload remains comparable. This supports investigating hypervisor scheduling or the platform's allocation model. On self-managed virtualization, inspect host oversubscription, CPU scheduling, and competing guests. In a public cloud, collect the evidence required for the provider's supported investigation path.
Third, load rises with blocked I/O or memory reclaim. Increasing vCPUs may leave the actual waiting resource unchanged. Use task state, storage latency, and pressure metrics to identify that path before changing compute size.
An illustrative noisy period
A virtualized database becomes slow when another host workload begins a scheduled task. Guest CPU usage alone looks lower than expected, but steal time and request latency rise together. Repeating a fixed query workload during and outside the overlap makes the scheduling relationship visible.
The infrastructure team reviews host allocation and moves or reschedules competing work through the approved process. It validates the same database workload afterward. The finding is scoped to the observed platform and interval; it does not assume every latency spike on a VM is caused by a noisy neighbor.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Runnable queue high; steal low | Guest compute pressure | Profiles, concurrency, and capacity |
| Steal rises with comparable load | Hypervisor scheduling delay | Host or provider evidence |
| Load high; tasks blocked on I/O | Waiting resource | Storage and task-state diagnostics |
| CPU metric absent or always zero | Accounting support question | Platform metric semantics |
A focused operator exercise
Use a repeatable workload in a controlled environment. Capture application completion, latency, per-CPU metrics, and run-queue behavior during a normal interval and an approved competing-load interval. Keep data size, software version, and request mix fixed.
Test a proposed host-placement, scheduling, or VM-capacity change independently. Verify improvement under the same workload and check other guests when operating the hypervisor yourself. Preserve the before-and-after intervals with timestamps and configuration details; a changed host identifier alone does not prove the performance cause.
Make escalation evidence useful
Provide the provider or virtualization owner with exact affected VM identities, intervals, workload symptoms, and correlated scheduling evidence. Avoid sending unrelated logs or sensitive payloads. State which alternative explanations were measured and which remain unresolved.
Keep CPU allocation assumptions in capacity planning, including disaster-recovery consolidation. Spare vCPU counts on a spreadsheet do not guarantee every recovered VM can receive its required execution time simultaneously.
Frequently asked questions
Is high load average proof of CPU saturation?
No. Inspect runnable work, blocked tasks, CPU execution, and other resource pressure together.
Does zero steal prove the hypervisor never delayed the guest?
Not universally. Check what accounting the platform exposes and use supported host or provider evidence where needed.
Continue the investigation
- VMware CPU ready: distinguish scheduling delay from guest CPU usage
- Linux Iowait: Connect CPU Accounting to Storage Evidence
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Server & Website Performance Troubleshooting to discuss implementation, validation and operational handover.
Technical reference
Virtualization Host Configuration and Guest Installation Guide