CLOUDTECHNOLOGIES- Shared vCPUs are overcommitted; dedicated vCPUs are reserved for you.
- CPU steal time shows when your VM is waiting for physical processor time.
- Shared plans suit development, testing and low-traffic sites.
- Production databases and latency-sensitive APIs benefit from dedicated vCPU.
When you rent a virtual server, the vCPU count on the spec sheet looks like a simple number. What it actually delivers depends on whether that vCPU is shared with other customers or reserved for you, and the difference shows most clearly when a production workload is under pressure.
Here is how shared and dedicated vCPUs work, how to spot contention and how to decide which one a workload needs.
What a vCPU actually is
A vCPU is a slice of a physical processor that a hypervisor presents to a virtual machine. On most platforms, one vCPU corresponds to one hardware thread on a physical core.
With shared vCPUs, the provider places more vCPUs on a host than it has physical threads, on the assumption that not every virtual machine will be busy at once. With dedicated vCPUs, each vCPU is backed by physical capacity that no other customer uses.
Noisy neighbors and CPU steal time
Overcommitment works well when demand is spread out. Problems start when several virtual machines on the same host get busy at the same time. Each one then waits for the hypervisor to schedule it onto a physical core, which is known as the noisy neighbor effect.
On Linux, this waiting shows up as steal time, the st value reported by tools such as top, vmstat and mpstat. It measures the share of time a virtual CPU was ready to run while the hypervisor was serving someone else. Occasional low steal time is normal on shared plans; sustained or spiky steal time means your application is losing processor time it expects to have.
Why predictability matters in production
For many production systems, consistency matters more than peak speed. A database that answers most queries in a few milliseconds but occasionally stalls creates timeouts, queue backlogs and frustrated users. Those tail-latency spikes are hard to debug, because the cause sits outside your virtual machine.
Dedicated vCPUs remove that variable. Benchmarks you run today reflect what you will get under load next month, which makes capacity planning and performance tuning far more reliable.
When shared is fine, and when to choose dedicated
Shared vCPUs are a sensible, economical choice for many workloads. Dedicated capacity earns its cost when performance is tied directly to revenue or user experience.
- Shared works well for development and test environments, low-traffic websites, internal tools, build runners with flexible deadlines and workloads that are idle most of the time.
- Dedicated is the better fit for production databases, APIs with latency targets, e-commerce checkouts, real-time processing, CPU-heavy batch jobs and AI inference.
A useful test is to track steal time and response-time percentiles on your current plan. If the 95th or 99th percentile drifts upward without any change in your own traffic, contention is a likely cause.
Dedicated cloud with Infinity Cloud
Infinity Cloud Technologies offers dedicated cloud with scalable, unshared vCPU power, designed for production workloads that need consistent performance. Because the vCPU capacity is not shared, your applications are not competing with other customers for processor time.
Dedicated cloud runs from Infinity Cloud’s data center in Romania, within the European Union, so teams can scale production workloads while keeping their data in the EU.