--- title: "CPU steal on a VPS: what it is, how to measure it, what to do | StreetHosting" description: "CPU steal is the time your VPS wanted to run but the host said no. Learn to measure it with top, vmstat, mpstat and sar, which values matter and what to do." url: "https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps" type: "page" language: "en-US" --- VPS · 9 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # Steal time: when your VPS waits for the host's processor Steal time is the most direct sign that your virtual machine is competing for CPU with others on the same host. Learn to measure it, tell noise from a real problem and build a ticket that support can actually investigate. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Hardware and datacenter](https://streethosting.com.br/en/guides/topics/hardware) [Linux administration](https://streethosting.com.br/en/guides/topics/linux) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=CPU%20steal%20on%20a%20VPS%3A%20what%20it%20is%2C%20how%20to%20measure%20it%2C%20what%20to%20do&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps "Share on LinkedIn") [](https://wa.me/?text=CPU%20steal%20on%20a%20VPS%3A%20what%20it%20is%2C%20how%20to%20measure%20it%2C%20what%20to%20do%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fwhat-is-cpu-steal-vps "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps.md) In this guide 6 sections * [What CPU steal is](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-e) * [How to measure it: top, vmstat, mpstat and sar](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#como-medir) * [Which values deserve attention](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#valores) * [Steal and overselling](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#overselling) * [What to do about high steal](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-fazer) * [Where to run sensitive workloads](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#onde-rodar) Quick answer **CPU steal**is the time your VPS had work ready for the processor, but the host was using the physical core for another virtual machine. It shows up as st in top and vmstat and as %steal in mpstat and sar. An average near zero is normal; sustained steal above 5% at peak hours already hurts games and APIs. In that case, measure for a few days, open a ticket with the data and, if that doesn't fix it, change plans or move to a dedicated server. ## What CPU steal is[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-e) On a KVM VPS, each vCPU of your virtual machine is, from the host's point of view, an ordinary thread that the Linux scheduler places on the physical cores. When all the processor threads are busy, your vCPU waits in a queue. The time it spent ready to work, waiting for a physical core to free up, is the steal time. The hypervisor reports that time to the VM's kernel, which is why you can see the wait from inside your machine. Think of a supermarket checkout split across several lines. You are ready to pay, but the cashier is serving another line. Nothing in your cart explains the delay: it comes from outside. Steal works the same way. The code didn't change, the database didn't change, and the request still took longer, because for a few milliseconds the VM simply didn't get any processor. Steal lives alongside other CPU usage measures, and knowing how to tell them apart avoids a wrong diagnosis: * **us and sy:** time spent by your code and by the VM kernel. High here means your workload is consuming CPU. * **wa:** time spent idle waiting on disk. It points to slow or saturated storage, not to the processor. * **id:** idle time, with nothing to do. * **st:**time stolen by the host. It is the only one of the four that you can't control from inside the VM. Steal only shows up when your VM wants to run. An idle VPS shows steal near zero even on a packed host, because it isn't asking for anything. That is why the measurement has to happen with the application under real load, preferably at peak hours. ## How to measure it: top, vmstat, mpstat and sar[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#como-medir) Four tools show steal, each with its own use. The first two already ship with Ubuntu; mpstat and sar are part of the sysstat package. ### top: the quick look[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#top) Run `top` and read the CPU line in the header. The last field is steal: `%Cpu(s): 38.2 us, 4.1 sy, 0.0 ni, 49.5 id, 0.3 wa, 0.0 hi, 0.4 si, 7.5 st` In the example, 7.5% of the vCPU time was taken by the host (top uses a period or a comma as the decimal separator depending on the language configured on the server). Press 1 inside top to see each vCPU separately. In htop, steal appears in the CPU bars when you enable the detailed CPU time option in the setup menu, under the F2 key. ### vmstat: one line per interval[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#vmstat) `vmstat 1 10 vmstat -t 60 >> ~/vmstat.log` The first command prints ten lines, one per second. Look for the st column in the cpu group. The second writes one timestamped line per minute to a file, which is useful to leave running through a peak afternoon inside tmux or screen. ### mpstat: steal per vCPU[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#mpstat) `sudo apt update && sudo apt install -y sysstat mpstat -P ALL 1 10` The %steal column appears for each vCPU and for the average. It helps when only some vCPUs suffer, which the top average hides. ### sar: the history that makes the case[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#sar) sar stores samples throughout the day and lets you look back, which is exactly what you need to prove a pattern. On some Ubuntu versions collection comes disabled: check the ENABLED line in the configuration file and enable the service. `sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat sudo systemctl enable --now sysstat # today, in 10 minute intervals sar -u # only the evening window sar -u -s 19:00:00 -e 23:59:00 # the 15th of the month, from the history file sar -u -f /var/log/sysstat/sa15` The output of sar -u includes the %steal column next to %user, %system and %iowait. After a few days of collection, you have a timestamped series, which is the most useful data in a ticket. For a general diagnosis of CPU, memory, disk and network right now, see [how to check CPU, RAM, disk and network on Linux](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux); for continuous tracking with charts, see the guide on [monitoring with htop and Netdata](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata). ## Which values deserve attention[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#valores) There is no official standard for steal. The numbers below are a practical reference for a VPS under production load, and what really counts is the value repeating at the moments your application suffers. | Measured steal | Reading | What to do | | ------------------------------------- | ------------------------------------------------------ | --------------------------------------------------------- | | Average near 0%, spikes of 1% to 2% | Normal noise on shared hardware | Nothing | | Spikes of 2% to 5% at specific times | Light contention during host peaks | Track it with sar and cross-check against the application | | 5% to 10% sustained at your peak hour | Significant contention, already affects games and APIs | Collect history and open a ticket | | Above 10% for long periods | Host overloaded for your workload | Ticket with evidence and an exit plan | The impact depends on the type of workload. A game server has a fixed deadline per tick, and a few milliseconds without a processor become a late tick. An API feels it as higher response time at the high percentile, the slowest 1% of requests. A nightly backup job barely notices, because it finishes a few minutes later and nobody is waiting. High steal alone, with no symptom in the application, is not yet a reason to migrate. High steal together with worse response time or TPS at the same hour is strong evidence. ## The relationship between steal and overselling[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#overselling) A physical host has a fixed number of threads. The provider decides how many vCPUs to sell on top of them. If the sum of vCPUs across all the VMs goes well past the number of physical threads and many of them work at the same time, the queue grows and steal shows up for everyone. Selling beyond physical capacity has a name, and the guide on [VPS overselling](https://streethosting.com.br/en/guides/vps/what-is-vps-overselling) explains how it happens in CPU, memory, disk and network. Steal is not automatic proof of overselling. A neighbor with a momentary spike, a maintenance routine on the host or a migration process can generate steal for a few hours on a well-sized server. The difference is in the pattern: an isolated episode is an incident; steal that comes back every day at the same hour is a capacity problem. ## What to do when steal is high[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-fazer) 1. **Rule out internal causes.** Confirm that what rises is st, not us or wa. An unindexed query, a looping process and a full disk produce similar slowness and are fixed inside the VM. 2. **Collect history.** Leave sar collecting for at least three to seven days, covering weekdays and the weekend. 3. **Cross-check with the application.** Note when the game lost TPS or the API got slow and check whether steal rose at that time. 4. **Open the ticket with data.** A report with times and numbers lets support cross-check against the host load and act. 5. **Decide the next step.** If the pattern continues after support has looked at it, change plans or product line, or move the workload to exclusive hardware. * Times of the episodes, with the time zone * IP or identifier of the VPS * sar output with the %steal column at those times * mpstat output during an episode, if you can capture one * What the application felt: TPS, response time or errors * Confirmation that us and wa were normal in the same period Adding more vCPUs rarely fixes steal, because the new vCPUs compete for the same physical processor. When the workload is already large and steal persists, the natural path is a dedicated server, and the step-by-step for the move, with inventory and cutover window, is in [migrating from a VPS to a dedicated server](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server). ## Where to run steal-sensitive workloads[](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#onde-rodar) No VPS provider can guarantee zero steal all the time, because shared hardware is the very definition of a VPS. What you can and should do is measure, on any provider, StreetHosting included: run sar during the first days and, if steal gets high at your peak hour, open a ticket with the data from this guide. For games, APIs and databases, the [Ryzen 9 9950X VPS](https://streethosting.com.br/en/vps/ryzen) runs on KVM, with DDR5, NVMe and boost up to 5.7 GHz. A faster core finishes the work sooner and spends less time in the queue. The tiers run from R$ 40.00 (1 vCPU and 2 GB) to R$ 846.00 (14 vCPU and 64 GB), including R$ 118.00 with 4 vCPU and 8 GB and R$ 222.00 with 6 vCPU and 16 GB. When the workload needs total predictability, a [dedicated server](https://streethosting.com.br/en/dedicated) removes the problem at the root: with no other virtual machines, there is no steal. In São Paulo, the AMD Budget SM comes with a Ryzen 9 5900XT and 64 GB of DDR4 for R$ 1,499.00, and the Extreme SM comes with a Ryzen 9 9950X and 128 GB of DDR5 for R$ 2,229.00, both with a 2 TB NVMe and a dedicated 10 Gbps. In this guide * [What CPU steal is](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-e) * [How to measure it: top, vmstat, mpstat and sar](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#como-medir) * [Which values deserve attention](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#valores) * [Steal and overselling](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#overselling) * [What to do about high steal](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#o-que-fazer) * [Where to run sensitive workloads](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps#onde-rodar) ## Frequently asked questions What is CPU steal on a VPS? It is the percentage of time your virtual machine had work ready for the processor, but the hypervisor was using the physical core for something else, usually another VM. Your application sits waiting even though nothing is wrong with your code. It shows up as st in top and as %steal in mpstat and sar. What steal time value is normal? As a practical reference, an average near zero and short spikes of one or two percent are normal noise on shared hardware. Sustained steal above 5% already hurts latency-sensitive applications, and above 10% for long periods means the host is overloaded for your workload. What matters is the value repeating at the times your application suffers. Is high steal my application's fault? No. Steal measures time the host took away from your VM, and no internal optimization reduces that number. Heavy use by your own code shows up in us and sy, and disk waits show up in wa. If what rises is st, the problem is outside your virtual machine. Does adding more vCPUs fix steal? Usually not. If the host is contended, the extra vCPUs compete for the same physical processor. What fixes it is your VM facing less competition on the host, which depends on the provider, or leaving shared hosting for a dedicated server, where there is no steal because there are no other virtual machines. How do I show support that my VPS has high steal? Collect history with sar for a few days, note the times when the application was slow and attach the mpstat output from those moments. Send the times with the time zone, the VPS IP, the steal values and what the application felt, such as response time or TPS. Timestamped data lets support cross-check it against the host load. Next step See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS. [See Ryzen VPS](https://streethosting.com.br/en/vps/ryzen) [See dedicated servers Exclusive hardware in São Paulo with NVMe and Anti-DDoS.](https://streethosting.com.br/en/dedicated) ## Related guides [VPS Intermediate VPS overselling: what it is and how to spot it Every VPS provider splits hardware between customers, and that is fine as long as you never feel the split. Here is how overselling happens in CPU, memory, disk and network, which signs show up inside your VPS, and how to test without jumping to conclusions. 10 min Read guide](https://streethosting.com.br/en/guides/vps/what-is-vps-overselling) [Infrastructure Advanced Migrate from VPS to dedicated server without surprises The VPS held up fine to a point, and now every night's peak tanks performance. This guide shows how to confirm the limit really is the machine and how to carry out the move to a dedicated server with a rollback plan ready. 10 min Read guide](https://streethosting.com.br/en/guides/infrastructure/migrate-vps-to-dedicated-server) [VPS Intermediate How to monitor VPS resources with htop and Netdata You only know you need a bigger plan once you can see the numbers. htop gives you a quick snapshot in the terminal, and Netdata gives you a full dashboard with CPU, RAM and disk history. 3 min Read guide](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata) [← Back to the Guide Center](https://streethosting.com.br/en/guides)