VPS plans list CPU as “2 cores” or “4 vCPU”. That number is useful, but it doesn’t tell the whole story. Here’s what it means and how to decide how many you need.

What is a vCPU?

A vCPU (virtual CPU) is a slice of processing capacity presented to your virtual machine as a CPU core. On a KVM host, each vCPU is a thread the hypervisor schedules on the physical processor’s cores or hyper-threads. Inside your VPS, nproc shows the count and lscpu the CPU model — see checking CPU info.

Key points:

  • A vCPU usually corresponds to one hardware thread, not necessarily a full physical core. With hyper-threading, two threads share one core’s execution units.
  • vCPUs from many VMs share the host’s physical cores. Most of the time VMs are idle, so this works well.
  • When the host is busy, your VM may wait for its turn — visible as steal time (st in top). See CPU steal time.

Single-thread speed vs number of cores

Workloads differ in how they use CPUs:

Mostly single-threaded — one core’s speed matters more than many cores:

  • Minecraft’s main game loop and many game servers
  • A single Node.js process
  • Many trading platforms (MetaTrader terminals and EAs)
  • Individual PHP requests (each request uses one core)

Multi-threaded or many processes — more cores help:

  • Web servers with many simultaneous visitors (PHP-FPM workers, Gunicorn workers)
  • Databases under concurrent load
  • Docker hosts running several services
  • Builds and compiles (make -j, npm run build for large projects)
  • Video encoding, compression, backups
  • Local AI inference on CPU

How many cores do you need?

Workload Starting point
Static sites, small bots, VPN, DNS 1 vCPU
One WordPress site with page caching 1–2 vCPU
Several WordPress sites, WooCommerce 2–4 vCPU
Node/Python app + database 2 vCPU
Docker host with many self-hosted apps 2–4 vCPU
Minecraft (small group), Valheim 2–4 vCPU (fast cores)
CI runners, builds 4+ vCPU
Busy database server 4–8+ vCPU
Local LLM on CPU 4–8+ vCPU with AVX2

CPU vs RAM: which is the bottleneck?

Upgrading the wrong resource wastes money. Check:

uptime            # load average vs nproc
top               # %us/%sy high → CPU busy; wa high → disk; st high → host contention
free -h           # "available" memory
vmstat 5          # r column (run queue) > cores → CPU-bound; si/so → swapping
  • Load consistently above the core count, CPUs busy → more cores or faster code.
  • Low CPU, high memory pressure → more RAM, not cores. See how much RAM a VPS needs.
  • High I/O wait → storage is the bottleneck; caching or faster storage helps more than CPU.

Making better use of the cores you have

  • Caching (page cache, object cache, CDN) removes most CPU work for websites.
  • Right number of workers: PHP-FPM pm.max_children, Gunicorn workers (2 × cores + 1 is a common start), PM2 cluster instances (one per core).
  • Background jobs for heavy tasks, so web requests stay fast.
  • Profiling before scaling: find the slow query or hot loop.

Benchmarks

Plans with the same core count can perform differently depending on CPU generation and host load. Compare with benchmarks like Geekbench or sysbench, ideally several times over a few days — see Linux benchmark tools.

Scaling up

Our VPS plans range from 1 to 14 vCPU cores, with RAM and storage scaling alongside — from small single-core servers to 14-core machines for databases and build servers. Plans are on KVM in USA, Hong Kong and Japan; moving to a bigger plan is a support ticket away when your monitoring shows the CPU is the limit.

  • VPS
  • CPU
  • Performance