{"id":32272,"date":"2026-07-23T11:43:02","date_gmt":"2026-07-23T09:43:02","guid":{"rendered":"https:\/\/contabo.com\/blog\/?p=32272"},"modified":"2026-07-23T11:50:46","modified_gmt":"2026-07-23T09:50:46","slug":"benchmark-vds-cpu-performance","status":"publish","type":"post","link":"https:\/\/contabo.com\/blog\/benchmark-vds-cpu-performance\/","title":{"rendered":"How to Benchmark VDS CPU Performance vs a Shared VPS"},"content":{"rendered":"\n

The two tests that actually prove dedicated CPU: monitor CPU steal time (%st in top or vmstat) over several hours, and run sysbench repeatedly rather than once. A one-shot benchmark score means nothing on its own \u2014 a shared VPS <\/a>can post the same number as a VDS<\/a> for thirty seconds and then collapse the moment a neighboring tenant gets busy. Sustained monitoring is what separates a real dedicated-core claim from a marketing one.<\/p>\n\n\n\n

Why a Single Benchmark Score Doesn’t Prove Dedicated CPU<\/h2>\n\n\n\n

Run Geekbench or sysbench once on a shared VPS<\/a> during a quiet moment and you can get a score that looks identical to a genuinely dedicated core. The difference only shows up under sustained load and across different times of day \u2014 a burstable, oversubscribed CPU allocation looks fine in a 20-second snapshot and throttles or fluctuates once you push it for longer, or once other tenants on the same physical host start competing for cycles. That’s why the tests below are built around duration and repetition, not a single run.<\/p>\n\n\n\n

Step 1: Check CPU Steal Time (%st)<\/h2>\n\n\n\n

CPU steal time is the single clearest signal. It measures the percentage of time your virtual CPU wanted to run but the hypervisor gave that cycle to another tenant instead \u2014 the direct fingerprint of a shared host.<\/p>\n\n\n\n

# Quick check
top
# Look for the %st value in the CPU line, e.g.:
# %Cpu(s):  ...  0.0 st

# Per-core detail over a minute
mpstat -P ALL 1 60

# Long sample \u2014 12 hours at 5-second intervals
sar -u 5 8640<\/code><\/pre>\n\n\n\n
Interpretation: 0-1% is typical of a genuinely dedicated allocation. 1-5% in occasional spikes is usually fine \u2014 brief hypervisor scheduling noise happens even on dedicated cores. 5-10% sustained is measurable contention worth investigating. Anything above 10% sustained means your “dedicated” CPU isn’t behaving like one, regardless of what the plan is called.<\/p>\n\n\n\n
Step 2: Run a Sustained sysbench Test, Not a One-Shot Benchmark<\/h2>\n\n\n\n
A single sysbench run tells you almost nothing. Run it repeatedly, across different hours \u2014 including peak times when other tenants on a shared host are most likely to be active \u2014 and look at the variance between runs, not just one number.<\/p>\n\n\n\n
# Install if needed
apt install sysbench

# Single run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run

# Repeated run \u2014 20 iterations, logging the time of each
for i in {1..20}; do
  date
  sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run
done<\/code><\/pre>\n\n\n\n
Compare the total-time and events-per-second figures across all 20 runs. A dedicated CPU allocation<\/a> should stay tight \u2014 results within a few percent of each other regardless of when you ran them. A shared VPS often shows real spread: one run at 20 seconds, the next at 21, then suddenly 35, then back to 25. Deviation beyond roughly 5-10% between runs is a strong signal you’re sharing physical cores with someone else’s workload.<\/p>\n\n\n\n
Step 3: Run a Long Endurance Test with stress-ng<\/h2>\n\n\n\n
Many shared VPS<\/a> plans allow short bursts of full performance before throttling kicks in \u2014 a CPU credit system that looks generous in a quick test and disappears under real, sustained load. An endurance test exposes this pattern directly.<\/p>\n\n\n\n
stress-ng --cpu $(nproc) --timeout 1h<\/code><\/pre>\n\n\n\n
Run this for a full hour while monitoring with htop or top in a second terminal. Watch for CPU frequency drops or a slowdown in task completion after the first 5-10 minutes \u2014 that’s the signature of a burst-then-throttle shared plan. A genuinely dedicated allocation should maintain flat, consistent performance for the entire hour.<\/p>\n\n\n\n
Reading Your Results: Pass or Fail<\/h2>\n\n\n\n\n
\n