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 — a shared VPS can post the same number as a VDS 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.
Why a Single Benchmark Score Doesn’t Prove Dedicated CPU
Run Geekbench or sysbench once on a shared VPS 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 — 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.
Step 1: Check CPU Steal Time (%st)
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 — the direct fingerprint of a shared host.
# 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 — 12 hours at 5-second intervals
sar -u 5 8640Interpretation: 0-1% is typical of a genuinely dedicated allocation. 1-5% in occasional spikes is usually fine — 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.
Step 2: Run a Sustained sysbench Test, Not a One-Shot Benchmark
A single sysbench run tells you almost nothing. Run it repeatedly, across different hours — including peak times when other tenants on a shared host are most likely to be active — and look at the variance between runs, not just one number.
# Install if needed
apt install sysbench
# Single run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run
# Repeated run — 20 iterations, logging the time of each
for i in {1..20}; do
date
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run
doneCompare the total-time and events-per-second figures across all 20 runs. A dedicated CPU allocation should stay tight — 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.
Step 3: Run a Long Endurance Test with stress-ng
Many shared VPS plans allow short bursts of full performance before throttling kicks in — a CPU credit system that looks generous in a quick test and disappears under real, sustained load. An endurance test exposes this pattern directly.
stress-ng --cpu $(nproc) --timeout 1hRun 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 — that’s the signature of a burst-then-throttle shared plan. A genuinely dedicated allocation should maintain flat, consistent performance for the entire hour.
Reading Your Results: Pass or Fail
Quick answer: a genuinely dedicated VDS CPU shows near-zero steal time, tight sysbench variance across repeated runs, and flat performance under a 1-hour stress-ng endurance test. A shared or oversubscribed VPS fails at least one of these three checks — use the table below to interpret your own results.
| Metric | Dedicated CPU (pass) | Shared / Oversubscribed (fail) |
|---|---|---|
| CPU steal time (%st) | 0–1% consistently, rare brief spikes | Sustained 5–10%+, spikes above 10% under load |
| sysbench run-to-run variance | Within a few percent across 20 runs, any time of day | Swings of 10%+ between runs, worse at peak hours |
| stress-ng 1-hour endurance | Flat performance for the full hour | Throttling or frequency drop after 5–10 minutes |
Verify Contabo’s Dedicated Cores With This Exact Method
Contabo’s Cloud VDS line – Max Performance VPS – ships with dedicated AMD EPYC cores as the default configuration, not an add-on — but you don’t have to take that on faith. Run the exact three tests above against a Cloud VDS instance yourself: check steal time over several hours, loop sysbench across peak and off-peak periods, and run the stress-ng endurance test for a full hour. A genuinely dedicated core should pass all three cleanly. Cloud VDS pairs that with NVMe storage by default, RAM-per-Euro value on the Core VPS line if you’re not ready for dedicated cores yet, and contract terms from month-to-month up to 24 months — so testing before committing to a longer term costs you nothing but the hour it takes to run stress-ng.
FAQ: Benchmarking VDS vs Shared VPS
0-1% consistently is what a genuinely dedicated allocation should show, with only occasional brief spikes into the low single digits. Sustained steal time above 5% is worth investigating; above 10% sustained means the CPU isn’t behaving like a dedicated core regardless of the plan name.
Not on its own. A single sysbench run can look identical on shared and dedicated hardware — the proof is in running it repeatedly across different times of day and comparing the variance. Pair it with CPU steal time monitoring for a complete picture; neither test alone is conclusive.
Longer than you’d think. A short burst test can pass on a burstable shared plan that throttles only after several minutes. Run sysbench in a repeated loop across at least a few hours spanning peak and off-peak times, and run a stress-ng endurance test for at least a full hour to catch throttling that a quick test would miss entirely.
