Overprovisioned host systems in virtualized environments often cause performance issues. Steal Time is a reliable indicator for identifying such bottlenecks. This article explains how to monitor Steal Time using top, the impact of high values, and how monitoring tools like Prometheus or Nagios can help identify long-term performance trends. Recently, a colleague asked for my help because one of his projects faced performance issues. The application, which had always run reliably, suddenly stopped delivering the expected performance. Despite no significant changes to the application, response times slowed, and users complained about long loading times. We traced the problem back to an overprovisioned host system. In these cases, a quick look at simple tools like top provides valuable insights into system load.

What is Steal Time?

Steal Time is a crucial indicator of issues on an overprovisioned host. This metric shows how much CPU time your virtual machine (VM) loses because the hypervisor allocates those resources to other VMs on the same physical host. In other words, your VM tries to use more CPU resources, but the hypervisor gives that Time to other systems. Running top quickly revealed the issue. The VM showed a high Steal Time, indicating that the hypervisor was overloaded and inefficiently distributed CPU resources.

How Steal Time Appears in the Guest VM

Even without direct access to the hypervisor, you can use the top command in the guest VM to see the st value. This value represents the percentage of CPU time that gets “stolen.”

Here’s an example:

In this case, 20% st means the VM loses 20% of its CPU time to other VMs. As a result, your VM doesn’t receive all the CPU performance it needs because the hypervisor reallocates that Time to other VMs on the same host.

Why Steal Time is a Reliable Indicator

The virtualization platform directly measures Steal Time, making it a reliable sign of overprovisioning. This metric operates independently of the guest operating system and clearly shows how much CPU time your VM loses. Industry benchmarks show that Steal Time values above 10% often lead to noticeable performance degradation, especially in database-heavy applications. Studies have also shown that Steal Time exceeding 20% can increase response times for web applications by as much as 30%.

• Direct feedback on CPU resources: Steal Time clearly shows how much CPU power your VM loses.

• Identifying overloading: When Steal Time consistently exceeds 10-20%, your environment is overprovisioned and your VM isn’t receiving the CPU performance it needs.

When Does Steal Time Become a Problem?

Not all Steal Time values are problematic. Low Steal Time (less than 5%) typically indicates occasional CPU resource redistribution and doesn’t cause significant issues. However, application performance will begin to suffer once Steal Time consistently exceeds 10-20%. The application struggled in my colleague’s project because the server couldn’t provide enough CPU resources. Long-term performance trends in virtualized environments emphasize the importance of regular monitoring of Steal Time. Automated monitoring tools like Prometheus or Nagios offer valuable capabilities for tracking both current Steal Time and trends that signal growing resource constraints.

• High Steal Time = Performance loss: High Steal Time means your VM isn’t getting the CPU time it needs, leading to performance degradation.

• Users notice the difference: In my case, the high Steal Time caused slower application response times, which users immediately noticed.

Conclusion

If your application isn’t performing as expected, and no changes have been made, check the Steal Time. It’s a reliable indicator that the hypervisor is overprovisioned and your VM isn’t receiving the necessary CPU resources. In my case, we quickly identified the problem as an overprovisioned host impacting application performance. We solved the issue by redistributing resources and reducing the number of VMs on the host, which restored the application’s performance to its previous levels.For long-term stability, run automated tests and continuous monitoring of system resources. Tools like Prometheus or Nagios can track performance trends and spot potential bottlenecks early, before they seriously affect performance.