{"id":1000,"date":"2026-08-28T22:47:15","date_gmt":"2026-08-28T22:47:15","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1000"},"modified":"2026-10-16T22:03:09","modified_gmt":"2026-10-16T22:03:09","slug":"vps-benchmark-cpu-memory-disk-io-tests","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-benchmark-cpu-memory-disk-io-tests\/","title":{"rendered":"Benchmarking a VPS Before You Commit: CPU Steal, Disk IOPS and Network Jitter in 20 Minutes"},"content":{"rendered":"\n

Synthetic benchmark scores are marketing. What matters for a production VPS is how the provider behaves under the contention patterns you will actually create: sustained CPU load, small random I\/O, and latency-sensitive network round trips. This article gives you a repeatable twenty-minute test suite that measures the numbers that predict real performance, and explains how to interpret them without fooling yourself.<\/p>\n\n\n

Use a throwaway instance. If the host passes, sign up. If you want a shortlist to test against, start from the VPS options on our main site<\/a>, which summarises the provider characteristics worth benchmarking in the first place.<\/p>\n\n\n

Measure CPU Steal First \u2014 It Explains Most Mysteries<\/h2>\n\n\n

On a VPS you share physical cores. Steal time is the fraction of time your vCPU was runnable but the hypervisor gave the physical core to someone else. High steal explains seemingly random latency spikes that no amount of application tuning fixes.<\/p>\n\n\n

grep ^cpu \/proc\/stat; vmstat 2 30 | awk '{print $16}' | tail -n +3 | sort -n | tail -5\nmpstat -P ALL 1 10 | grep -E \"Average|%steal\"<\/code><\/pre>\n\n\n
Run these while generating load with sysbench cpu --threads=$(nproc) run<\/code>. Steal above roughly five percent on a dedicated-vCPU plan is a red flag; a few percent as a brief spike under neighbour pressure is normal. Record the maximum, not the average, because latency-sensitive workloads feel the peaks.<\/p>\n\n\n
Also capture per-vCPU variance. If one vCPU consistently shows much higher steal than the others, you may be pinned to a busy physical core and no amount of tuning will help. This is a provider-level problem, so it belongs in your go or no-go decision.<\/p>\n\n\n
Disk Benchmarks That Reflect Real Workloads<\/h2>\n\n\n
dd<\/code> with a big block size measures sequential throughput, which almost nothing uses. Databases and mail queues do small random reads and writes with a queue depth above one. Use fio<\/code> with a mixed read\/write profile and watch the latency percentiles.<\/p>\n\n\n
fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --bs=4k \\\n  --iodepth=16 --numjobs=4 --size=1G --runtime=60 --time_based \\\n  --group_reporting<\/code><\/pre>\n\n\n
Capture iops<\/code>, bw<\/code>, and the clat percentiles<\/code> block. The p99 read latency is the number that matters for interactive services. Sequential throughput with --bs=1M --rw=read<\/code> tells you about backup and restore times, which is a different question and deserves its own figure.<\/p>\n\n\n