Every VPS quote lists vCPU counts next to memory and disk. The number is real, but the small print decides what it means. On a shared plan that core is yours until someone else on the same host wants it, and then you are queuing. On a dedicated plan the core is pinned to you. The price gap between the two exists for a reason, and the reason shows up in your p99, your average, or your wallet, depending on which one you picked.
Here is what is actually happening inside the box, how to measure it, and where the dedicated premium pays for itself.
Linux tracks a fifth CPU state alongside user, system, idle and I/O wait. It is called steal time, and top shows it as st. Steal is the time your virtual machine was ready to run a thread but the hypervisor gave the physical core to someone else. It is not your kernel being slow. It is your kernel waiting in a queue you cannot see.
Check it with vmstat 1. The st column is steal as a percentage of each second. On a quiet dedicated slice you will see 0.0 almost all the way down the output. On an oversold shared plan you might see 2 to 5 percent at 3am and 15 to 30 percent during the working day, which is exactly when your users are on the site.
One caveat before you panic at a single reading: steal spikes once a day mean your neighbour ran a cron job. Sustained steal across a full day means the host is oversold by design. Pull 24 hours of data before you draw a conclusion.
Steal does something specific to your response times. It shifts work from the fast requests to the slow ones. A 5 percent steal rate barely moves an average, because most requests gain a millisecond here and there. But a request that lands while the hypervisor is busy can lose 50 or 100 milliseconds in one go, and a queue has to drain before your thread runs at all.
The result is a p99 that climbs while your p50 barely moves. A store that feels quick when you test it yourself and loses checkout clicks at 8pm is the classic signature. We covered the same shape from the disk side in our piece on IOPS versus throughput for database workloads: the average hides the tail, and the tail is what a customer experiences.
If your monitoring only reports the mean, you cannot see this at all. Graph p95 and p99 before you blame the application.
The honest answer is that most small workloads do not. A brochure site, a low-traffic API, a mail server handling a few thousand messages a day: all of these run fine on burstable shared cores, because they spend most of their life idle and can absorb a stolen millisecond without anyone noticing.
Dedicated vCPU earns its premium in three cases:
One more case worth naming: noisy-tenant-sensitive multi-tenant software. If you host other people's sites, you inherit their traffic peaks, and shared CPU under-provisioning surfaces as customer complaints rather than as your own latency graph.
Marketing names differ by provider. You will see "burstable", "standard", "shared" on one side and "dedicated", "pinned", "premium" on the other. Ignore the names and ask two questions.
First: is the core time guaranteed or best effort? Some hosts publish a CPU credits system, where you earn time when idle and spend it when busy. That is a fair model for spiky workloads and a poor one for sustained ones, because the credits run out exactly when your load does not.
Second: is the underlying host oversubscribed, and by what ratio? A 2:1 shared host with a strict steal alert is a better deal than a "dedicated" core on a host running 8:1 with no monitoring. Reputable providers publish or will state their oversubscription ratio if asked. Ask, and treat a refusal to answer as the answer.
Before upgrading, measure what you actually use. pidstat gives per-process CPU over time; sar -u gives history if sysstat is installed. If your p95 CPU sits under 40 percent all day, your problem is elsewhere, and buying dedicated cores buys you nothing. Read the storage numbers alongside it, since the two interact.
If steal is sustained above about 5 percent and your p99 tracks it, move the workload that is queuing first. On most stacks that is the database, and a dedicated core or two there costs a fraction of moving the whole server.
Dedicated CPU removes one variable. It does nothing for the ones that take servers down: power, network failure, disk death, or the maintenance windows your provider schedules. What an SLA covers, and what it does not, is a separate decision we broke down in our piece on what a 99.9 percent uptime promise really commits you to.
The short version: match the core model to the workload, measure steal before blaming your code, and pay for the dedicated tier only where the tail latency shows up in money. If you want a London box sized against your real numbers rather than a generic tier, mail admin@servercabin.com with what you run and we will benchmark your workload on the exact slice before you commit to it.