Does CPU Steal Time Change What I Should Buy?

At Hostna, we run our own platform with a focus on hardware transparency, ensuring that you have the data needed to diagnose performance bottlenecks. When you observe the metrics of your virtual private server, one specific figure often causes confusion: CPU steal time. Represented as st in common monitoring tools, this metric indicates the duration your virtual machine spent waiting for the physical processor while the hypervisor was busy servicing other guests or managing system overhead. If this number is consistently high, it fundamentally changes what you should buy, shifting the requirement from a shared vCPU model to a machine with dedicated resources.

Understanding the Hypervisor Scheduler

To understand why steal time occurs, you must look at how a Kernel-based Virtual Machine manages resources. In a shared environment, the hypervisor uses a scheduler to distribute physical CPU time slices among multiple virtual machines. A vCPU is not a physical processor but a time-slice on a shared thread, governed by the hypervisor’s scheduler. When your guest operating system has a process ready to run, it sends a request to the hypervisor. If the physical CPU is currently occupied by another tenant, your guest must wait. This waiting period is recorded as steal time.

This mechanism is inherent to the multi-tenant nature of Linux virtual machines. While the scheduler attempts to be fair, excessive oversubscription on a physical node leads to a scenario where the total demand for CPU cycles exceeds the physical capacity. In such cases, even a lightly loaded guest might experience steal time because the hypervisor cannot find an available slot on the physical core. This differs from iowait, which indicates the CPU is waiting for disk or network I/O; steal time is purely about processor availability.

Measuring Steal Time on Your Instance

You can observe the specific steal percentage by running top -b -n 1 and looking at the st column. For a more granular view over time, the mpstat command from the sysstat package is highly effective. Use the following command to monitor all CPU cores every second:

mpstat -P ALL 1 10

In the output, the %gnice and %steal columns provide the necessary data. If the %steal value is consistently above 5.0, your applications will likely experience latency. For high-performance applications, even a value of 1.0 can be problematic. This is particularly true for tasks that require low database latency, where every millisecond spent waiting for the CPU translates directly into slower response times for your users.

The Impact on Database and Application Performance

The presence of steal time has a compounding effect on system performance. For instance, if your PHP-FPM pool is configured with pm.max_children = 20, each child process requires CPU time to handle its request. High steal time forces these children to wait, increasing the memory pressure as processes stay alive longer than necessary. A PHP-FPM pool with pm.max_children = 10 and a 512 MB memory_limit can claim 5 GB in the worst case, which is why a 4 GB machine that looks idle can still be killed by the OOM killer during one traffic spike — the ceiling is max_children x memory_limit, not average usage.

Setting innodb_buffer_pool_size to a value that represents roughly three quarters of your available RAM is standard practice for MariaDB or MySQL. However, if the CPU is stolen, the time it takes to process the data within that buffer increases. The kernel’s ability to manage memory via cgroup limits is also affected; when steal time is high, the kernel’s memory management thread may not run frequently enough to swap out idle pages, potentially leading to a system hang. This is why a workload that performs well on a machine with 0 percent steal time might fail on a machine with 10 percent steal time, even if the RAM and disk IOPS are identical.

When Steal Time Forces a Change in Hardware

If your monitoring shows sustained steal time, the plan you are on may no longer be appropriate for your workload. There are two primary reasons to change your purchase strategy. First, if your application is latency-sensitive, such as a real-time trading platform or a high-traffic e-commerce site, any amount of steal time is unacceptable. In these cases, you should move to a tier that offers dedicated physical cores. This eliminates the scheduler contention because the hypervisor pins your vCPUs to specific physical threads using cpuset.

Second, if you are running complex automation workflows that involve heavy cryptographic operations, such as TLS 1.3 handshakes or ZFS checksumming, the CPU demand is high. While the TLS 1.3 one-RTT handshake reduces initial connection delay, the cryptographic verification of the certificate chain is CPU-intensive. On a machine with high steal time, this handshake can take significantly longer, degrading the experience for every new connection. Moving to a VDS or a dedicated server ensures that the CPU cycles you pay for are always available when the kernel requests them.

Distinguishing Between Contention and Throttling

It is important to distinguish between steal time caused by other tenants (contention) and steal time caused by your own resource limits (throttling). Some cloud architectures use a credit-based system where your CPU usage is throttled once you exhaust your allocated credits. This will also appear as steal time in your metrics. However, on our platform, we focus on providing consistent performance without hidden credit caps. If you suspect contention, the Hostna dashboard provides the first point of reference for node status and any reported maintenance.

To verify if the issue is local to your configuration, check your own resource usage. If your CPU usage is near 100 percent and you see steal time, it might be the hypervisor enforcing your plan’s limits. If your CPU usage is low (e.g., 20 percent) but steal time is high (e.g., 15 percent), you are almost certainly facing resource contention from other guests on the same physical host. In this scenario, consulting the technical documentation or checking the service level agreement regarding resource allocation is the next logical step.

Sizing Your Next Purchase Based on Steal Tolerance

When selecting your next server, use the following table to match your workload’s tolerance for steal time with the appropriate hosting tier. This prevents overspending on dedicated resources for tasks that can handle minor delays, while ensuring critical applications have the stability they require.

If you find that your current hosting control panel is reporting slow response times despite low internal load, check the st metric immediately. If the numbers consistently exceed the tolerances listed above, the most effective path forward is to migrate to a hardware environment where CPU cycles are not shared. This transition resolves the root cause of the delay, ensuring that your software execution is limited only by the clock speed of the physical processor and the efficiency of your code, rather than the scheduling decisions of a hypervisor.

This article was drafted with AI assistance from Hostna’s own research pipeline and read by a person before publication.