CPU Performance: Cores, vCPUs and When More Does Not Help

Shopping for a VPS by raw vCPU count is the fastest way to overspend on performance you will never use. A database that is bottlenecked on a single query path will not run faster because you gave it eight cores; a Python web tier that is mostly idle will not notice four more. CPU sizing is really about two separate questions: how much parallelism can your workload actually use, and how well does each vCPU deliver work per unit of time.

What a vCPU really is

A vCPU is a virtual processor that the hypervisor overlays on physical cores. On Netbay nodes, those physical cores are Intel Xeon Platinum. A vCPU does not carry a fixed speed because it competes with neighbours for the same physical resources, but for well-behaved workloads it behaves like a dedicated core most of the time. The practical rule: one vCPU can execute one thread of work at a time, and it runs at roughly the speed of the physical core it lands on.

The conversion matters. A burst of single-threaded work cares about core speed, not core count. A batch of independent jobs cares about core count. If you do not know which category your workload is in, sizing is guesswork.

Recognizing parallelism you can actually use

A workload is CPU-bound when it spends most of its time executing instructions, and embarrassingly parallel when the work splits into independent chunks. Web servers that run one request per worker, build pipelines, and batch workers split naturally. A single monolithic report or a speed-of-single-query database does not.

• **Bottlenecked on one request**: the whole path is serial; extra cores idle.
• **One request fans out to many small jobs**: this can scale to several cores.
• **Many concurrent requests**: this scales to many cores, up to the concurrency limit.

The surest way to know is to watch utilisation under real load. A server at 100 percent on one core and 5 percent on six others is not under-powered; it is single-threaded. Throwing vCPUs at it changes nothing.

A simple concurrency probe

To see how many threads your workload actually keeps busy, watch instantaneous CPU per core rather than the aggregate. This short loop prints utilisation for every logical CPU:

for i in $(seq 1 6); do
  grep 'cpu[0-9]' /proc/stat |     awk -v n="$i" 'NR==n {u=$2+$4; t=u+$5; printf "core %d busy %.0f%%\n", NR-1, (u/t)*100}'
  sleep 2
done

If only one or two "core busy" lines are high while the rest sit near zero, your app is single-threaded or low-concurrency, and no core count will fix it. If all lines are uniformly high, you are genuinely parallel and more vCPUs may help.

Measuring headroom the honest way

The aggregate metrics fool you. Percentage-of-CPU utilisation and load average mix idle, wait, and steal, so a supposedly busy server can be spending most cycles blocked on I/O, and a server at low average can be bursting through spikes. Use per-core busy time and the steal column together:

mpstat -P ALL 2 5
uptime
cat /proc/vmstat | grep -E '^nr_(running|blocked)'

nr_running tells you how many threads want the CPU right now. When it climbs well above the vCPU count, the server is genuinely compute-starved and a bigger instance is the correct move. When it stays near zero while your app feels slow, the bottleneck is elsewhere and adding cores is wasted spend.

When adding cores does not help

• **Latency-bound work**: a user waits on a request round-trip; core count is irrelevant.
• **Single-threaded workloads**: one vCPU services one chain; the rest sit idle.
• **I/O-bound workloads**: threads block on disk or network; extra cores do not remove the wait.
• **Already capped by concurrency**: an app configured for two workers cannot use four cores.

For these, the fix is software: tune thread pools, split the single hot query, shard the work. Adding CPU is paying for idle silicon.

Takeaway

Size CPU by parallelism, not by marketing. Measure nr_running and per-core busy time under real load before you spend on more vCPUs. When you do need more genuine compute, you can resize an instance on Netbay from the dashboard or the API at netbayhosts.in, deployed in under 60 seconds.