vCPU vs vCore: how to read VDS specs and not get fooled

Two providers can both advertise “2 vCPU” at wildly different prices, and the cheap one isn’t always the worse deal — sometimes it is exactly the same hardware, and sometimes it is a quarter of the performance shared with a crowd. The label alone won’t tell you which. To read a VDS plan honestly, you need to know what sits underneath the word “core,” and what a provider quietly leaves out of the spec sheet.

Core, thread, vCPU: three different things

A modern server CPU has a fixed number of physical cores — actual silicon that does the computing. With simultaneous multithreading (Intel calls it Hyper-Threading, AMD calls it SMT), each physical core exposes two hardware threads to the operating system. Those two threads share one core’s execution units; they are not two independent cores. When both threads are busy with heavy work, they compete, and you typically see well under the 2x you might naively expect.

A vCPU is the unit the hypervisor presents to your VM. In the common case, one vCPU maps to one hardware thread. So a “2 vCPU” plan is usually two threads — which, depending on the host, might be one full physical core’s worth of capacity or two threads borrowed from two different busy cores. “vCore” is just a marketing synonym for vCPU; it does not promise you a dedicated physical core, no matter how solid the word sounds.

The real question is never how many vCPUs you get. It is how much of each one is actually yours.

Oversubscription: the number nobody prints

Here is the part the spec sheet hides. A host with, say, 64 threads does not have to sell only 64 vCPUs. The hypervisor lets a provider allocate far more vCPUs than there are physical threads, betting that not every customer is busy at once. That ratio — vCPUs sold per real thread — is the oversubscription or contention ratio.

At a 1:1 ratio, your vCPU is always there when you reach for it. At 4:1 or 8:1, your “2 vCPU” might be sharing each thread with three or seven other tenants. When your neighbours are idle, you feel fine. When the host gets busy — and it will, because everyone’s traffic peaks around the same hours — your CPU time gets rationed, and your application slows down for reasons that have nothing to do with your own load.

The most important CPU number on a VDS plan is the one almost no provider prints: how many customers share each thread.

Oversubscription is not inherently fraud; it is a legitimate engineering trade-off that keeps prices low. The problem is that it is invisible. You cannot see it in htop, you cannot benchmark for it at 3 a.m. when the host is quiet, and you only discover it when your response times wobble under load with no explanation in your own metrics.

CPU steal: how to actually measure it

Fortunately, contention leaves a fingerprint. When the hypervisor wants to give your vCPU time on a physical thread but that thread is busy serving someone else, your VM is left ready to run but waiting. Linux records exactly this as CPU steal time — the %st column.

Open top and press 1 to expand per-core lines, or run mpstat for a cleaner view:

$ mpstat 1 5
# ...
# CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
# all  12.0  0.00  3.1     0.4  0.0   0.2   18.7   65.6

A steady single-digit %steal is normal background noise. Sustained double digits — like the 18.7% above — mean you are paying for CPU you are not allowed to use. The host is oversubscribed and contended, and that figure is a direct, honest measurement of how much of your “2 vCPU” is being eaten by neighbours.

Base clock, boost clock, and why both matter

A thread’s speed matters as much as its availability. CPUs advertise two numbers: a base clock they can sustain across all cores indefinitely, and a higher boost clock they hit briefly on a few cores when thermal and power headroom allow. Marketing loves the boost number; your steady workload lives near the base number.

On a shared host running many busy VMs, the all-core load pins the CPU close to base clock — boost rarely kicks in for you, because the silicon is already working hard for everyone. So when a plan mentions a clock speed, ask which one it is. A high boost figure on a crowded host is a number you will almost never see in production.

What to ask a provider before you buy

Read past the headline vCPU count and ask plainly:

• Are the vCPUs dedicated, or shared with an oversubscription ratio — and what is that ratio?
• Does one vCPU map to a full physical core or to a single SMT thread?
• What is the base clock of the underlying CPU, not just the boost?
• Is CPU steal capped or monitored, and what figure is considered normal?
• Can I run my own mpstat during peak hours and see honest numbers?

A provider that can answer these without hedging is telling you the spec sheet is real. One that deflects is telling you something too.

How Cybeward maps plans to real resources

At Cybeward the answer is short, which is the point. CPU, RAM and disk are real allocated resources behind each billing product — we do not oversubscribe. When a plan says a given number of vCPUs, that capacity is reserved for your VM, so your %steal stays at the noise floor instead of climbing when a neighbour gets busy. The numbers in the plan are the numbers you get, backed by our 99.999% SLA, and you are welcome to run mpstat and confirm it yourself. We would rather you read the spec sheet closely — because ours holds up when you do.

#cpu#vds#infrastructure