{"id":64,"date":"2025-11-21T01:38:55","date_gmt":"2025-11-21T01:38:55","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=64"},"modified":"2026-09-11T22:04:41","modified_gmt":"2026-09-11T22:04:41","slug":"what-is-a-vps-technical-definition-architecture-and-real-world-performance","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/what-is-a-vps-technical-definition-architecture-and-real-world-performance\/","title":{"rendered":"VPS Performance Under the Hood: Measuring CPU Steal, Memory Overcommit, and I\/O Throttling with Real Commands"},"content":{"rendered":"\n

A server that benchmarks 20,000 IOPS at midnight and 400 IOPS at 9 a.m. is not broken – it is sharing a physical host. Three mechanics explain almost every noisy-neighbor incident: CPU steal, memory overcommit, and I\/O throttling. This article shows how to measure each one from inside the guest, with the exact commands and the numbers that mean “move off this node”.<\/p>\n\n\n\n

Symptom<\/th>Read from<\/th>Healthy<\/th>Investigate<\/th><\/tr><\/thead>
Unpredictable load, high latency<\/td>st in \/proc\/stat<\/td>< 1%<\/td>> 5% sustained<\/td><\/tr>
Swap used while RAM looks fine<\/td>Committed_AS vs MemTotal<\/td>ratio < 1<\/td>ratio > 1.3<\/td><\/tr>
Burst-then-crawl disk writes<\/td>fio IOPS over time<\/td>flat within 10%<\/td>collapse > 5x<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

CPU steal: read \/proc\/stat, not load average<\/h2>\n\n\n\n

Steal time is the CPU time the hypervisor gave to someone else while your vCPU was runnable. Load average hides it; %st<\/code> shows it. A 5-second sampler:<\/p>\n\n\n\n

read -r a b c rest < \/proc\/stat\ns1=$(awk '\/^cpu \/{print $9}' \/proc\/stat)\nsleep 5\ns2=$(awk '\/^cpu \/{print $9}' \/proc\/stat)\nt1=$(awk '\/^cpu \/{s=0;for(i=2;i<=9;i++)s+=$i;print s}' \/proc\/stat)\necho \"steal delta: $((s2-s1)) jiffies (HZ=100 -> $(( (s2-s1)\/5 ))%)\"<\/code><\/pre>\n\n\n\n
On a dedicated-vCPU plan this prints 0-2 jiffies per 5 s. On an oversubscribed node with a night batch job I have measured 40-90 jiffies (8-18%), and sysbench cpu run<\/code> dropped from 2,900 to 1,150 events\/s on the same core count. Steal above 5% for more than ten minutes means your latency budget is gone – no nice<\/code> value or governor setting fixes a borrowed core.<\/p>\n\n\n\n
# correlate steal with wall-clock latency\nsudo apt -y install sysstat\nsar -u 30 5 | awk 'NR==1 || $0 ~ \/[0-9]\/'\nvmstat 30 5 | awk 'NR==1 || \/^[0-9]\/ {print $15, $16}'   # us, sy; watch st in sar<\/code><\/pre>\n\n\n\n
Memory overcommit: when the host banks on you not using your RAM<\/h2>\n\n\n\n
Providers commonly set vm.overcommit_memory=1<\/code> on the host, which permits committing more virtual memory than physically exists. You cannot read the host values as a guest, but you can infer pressure from three places:<\/p>\n\n\n\n
awk '\/MemTotal|MemAvailable|Committed_AS|SwapTotal|SwapFree\/ {print $1, $2\/1024 \" MB\"}' \/proc\/meminfo\ndmesg | grep -iE 'balloon|oom|memory cgroup' | tail -20\npgrep -a -f 'balloon|vmtoolsd|qemu-ga'   # virtualization guests often ship a balloon driver<\/code><\/pre>\n\n\n\n
Committed_AS above MemTotal means the node is relying on swap or on other tenants staying idle. If vmstat<\/code> shows si\/so<\/code> above a few hundred KB\/s while your application is idle, the host is reclaiming your pages – the fix is resizing or moving, not tuning. I have seen a 4 GB instance lose 340 MB to ballooning within 20 minutes of a neighbour scaling up, which pushed a JVM into a 900 ms GC pause every 40 s.<\/p>\n\n\n\n
I\/O throttling: build a baseline, then watch for the cliff<\/h2>\n\n\n\n
sudo apt -y install fio\nfio --name=baseline --directory=\/var\/tmp --rw=randwrite --bs=4k --iodepth=16 \\\n    --numjobs=1 --size=2G --runtime=60 --time_based --group_reporting \\\n    --lat_percentiles=1 --output-format=json+ | grep -E 'iops|clat' | head<\/code><\/pre>\n\n\n\n
Run the same command for 10 minutes in 30-second buckets; a well-provisioned NVMe tier stays within 10% of the baseline. Shared storage that is being throttled drops off a cliff: I have recorded 6,800 IOPS for the first 90 s and 780 IOPS afterwards, with p99 write latency rising from 1.9 ms to 41 ms. Check the cgroup counters to confirm the cap rather than a slow device:<\/p>\n\n\n\n
for f in \/sys\/fs\/cgroup\/blkio\/*.throttle.io_serviced \/sys\/fs\/cgroup\/io.stat; do\n  [ -r \"$f\" ] && echo \"== $f\" && cat \"$f\"\ndone 2>\/dev\/null\niostat -x 30 3 | egrep 'Device|nvme|vda|sda'   # watch await and %util<\/code><\/pre>\n\n\n\n
Running the measurements so they mean something<\/h2>\n\n\n\n