{"id":21,"date":"2025-10-24T11:32:47","date_gmt":"2025-10-24T11:32:47","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=21"},"modified":"2026-09-14T22:03:19","modified_gmt":"2026-09-14T22:03:19","slug":"what-is-vps-virtual-private-server-definition-complete-guide","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/what-is-vps-virtual-private-server-definition-complete-guide\/","title":{"rendered":"vCPU Shares, RAM Overcommit, and I\/O Limits: The Numbers Behind a VPS Spec Sheet"},"content":{"rendered":"\n

Two VPS plans can advertise “2 vCPU \/ 4 GB \/ NVMe” and deliver 4x different throughput under load. The number on the order page is a ceiling, not a guarantee. This article works through what the ceiling actually means \u2014 the scheduler weights, the overcommit ratio, and the I\/O throttle \u2014 and shows you how to measure your real allocation in about ten minutes.<\/p>\n\n\n\n

CPU: Shares Are Weights, Not Cores<\/h2>\n\n\n\n

KVM guests run as Linux threads on the host, scheduled by CFS (Completely Fair Scheduler). A guest with 2 vCPU is two host threads with a `cpu.shares` weight. The default weight per core is 1024. A provider that sets your two cores to shares=2048 while a neighbour runs eight cores at shares=8192 is telling the scheduler to give you 1\/5 of the contention window when both are runnable. On an idle host you get the full two cores; on a busy host you get your weight ratio.<\/p>\n\n\n\n

Allocation model<\/th>Contract<\/th>Typical steal under load<\/th>Best for<\/th><\/tr><\/thead>
Shared \/ overcommitted<\/td>cpu.shares weight only<\/td>3\u201315%<\/td>bursty web traffic, dev boxes<\/td><\/tr>
Fair-share cgroup cap<\/td>`cpu.max` quota (e.g. 200000\/100000)<\/td>< 2% of quota<\/td>steady web apps<\/td><\/tr>
Dedicated vCPU pinning<\/td>`cpuset` \u2014 exclusive physical cores<\/td>0\u20130.5%<\/td>databases, latency-sensitive APIs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Verify what you got. Steal time near zero plus a load average that tracks real work means you are effectively exclusive. Sustained steal above 4% under your own saturated load means you are sharing.<\/p>\n\n\n\n

# Is your vCPU actually available? Saturate and watch steal for 30s.\nsudo apt install -y sysstat\nfor i in $(seq 1 $(nproc)); do (yes > \/dev\/null &) ; done\nvmstat 1 30 | awk 'NR==1||NR>2{print}'\npkill yes\n# Interpretation: r column >> nproc is fine; st column = steal, that is the number to watch.<\/code><\/pre>\n\n\n\n
Memory: The Overcommit Ratio Decides Your Swap Rate<\/h2>\n\n\n\n
`MemTotal` inside the guest is never the story. The story is `vm.overcommit_ratio` and whether the host uses KSM and swap-backed guest memory. On a 1:1.5 host you will essentially never swap. On a 1:3 host, the hypervisor can balloon your guest and you will see swap activity that your own `swappiness` setting did not cause. Detect it before it becomes an incident:<\/p>\n\n\n\n
# Inside the guest \u2014 page faults and swap-in from host pressure\ngrep -E 'pgmajfault|pswpin|pswpout' \/proc\/vmstat\n# Watch major faults per second; a steady non-zero rate at idle load = host memory pressure\nwhile :; do grep -E 'pgmajfault' \/proc\/vmstat; sleep 5; done<\/code><\/pre>\n\n\n\n
A useful rule for a 1 GB\u20134 GB instance: keep your application working set at or below 70% of `MemTotal`, and keep swap at 1\u20132 GB on NVMe. That leaves 30% as page cache headroom, which is where most of your read performance lives.<\/p>\n\n\n\n
Storage: IOPS Throttling Is Invisible Until It Bites<\/h2>\n\n\n\n
Cloud providers enforce disk throughput with a token bucket, usually in the hypervisor’s blkio cgroup. You will not see it in `IOPS` on the invoice \u2014 you see it as latency spikes at consistent intervals. The tell-tale: latency that is flat at low queue depth and then jumps to tens of milliseconds at the exact same point every time.<\/p>\n\n\n\n
# Locate your throttle ceiling with fio at increasing queue depth\nfor qd in 1 4 16 32 64; do\n  echo \"--- QD $qd ---\"\n  fio --name=vm --filename=\/tmp\/fio.tmp --size=1G --bs=4k --rw=randread \\\n      --iodepth=$qd --ioengine=libaio --direct=1 --runtime=20 --time_based \\\n      --group_reporting 2>\/dev\/null | grep -E 'iops=|lat \\(usec\\)'\ndone\nrm -f \/tmp\/fio.tmp<\/code><\/pre>\n\n\n\n
Plot IOPS against queue depth. A healthy NVMe disappears into the ether until ~64 QD. A throttled plan goes flat at, say, 3000 IOPS while latency doubles at each step \u2014 that is your token bucket, and no amount of application tuning will move it.<\/p>\n\n\n\n
What to Do With the Numbers<\/h2>\n\n\n\n