VPS Benchmark Checklist

A short, repeatable benchmark for any Linux VPS. Run it on a new server before you trust it, and again whenever performance feels off.

1. System info — what did you actually get?

Before benchmarking, confirm the VPS matches the plan you bought. Providers occasionally oversell, mislabel CPU models, or hand out less RAM than advertised.

# CPU model, cores, virtualization
lscpu

# Kernel and distro
uname -a
cat /etc/os-release

# Memory
free -h

# Disk layout
lsblk
df -h

# Is this KVM, OpenVZ, LXC?
systemd-detect-virt

Red flags: a CPU model from 2012 on a "high-performance" plan, RAM that's 20%+ below advertised, or systemd-detect-virt reporting openvz when you paid for KVM. Some providers state the virtualization type up front on the plan page — MonoVM's VPS catalog is one example that lists CPU, RAM, storage type, and virtualization per plan, which saves you the post-purchase audit.

2. CPU performance

Use sysbench for a quick single-thread and multi-thread score.

# Install
apt update && apt install -y sysbench   # Debian/Ubuntu
dnf install -y sysbench                  # AlmaLinux/Rocky

# Single thread
sysbench cpu --cpu-max-prime=20000 --threads=1 run

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

Compare the "events per second" number across providers. For a modern dedicated-core VPS, expect single-thread events/sec well above 1,000. Shared/burst plans will be lower and uneven.

3. RAM size and speed

# Total and available memory
free -h

# Memory bandwidth (rough)
sysbench memory --memory-block-size=1M --memory-total-size=10G run

If free -h shows noticeably less than the advertised plan, factor in kernel reserves — but a 1 GB plan showing 700 MB available is normal; 1 GB plan showing 480 MB is not.

4. Disk I/O

Disk speed is where VPS plans differ most. NVMe vs SATA SSD vs network-attached storage will show 5–20x gaps.

# Quick sequential write
dd if=/dev/zero of=/tmp/test.img bs=1M count=1024 conv=fdatasync
rm /tmp/test.img

# Realistic mixed I/O with fio
apt install -y fio
fio --name=randrw --rw=randrw --bs=4k --size=1G --numjobs=1 \
    --runtime=30 --time_based --group_reporting --filename=/tmp/fio.img
rm /tmp/fio.img

Look at IOPS for the random read/write workload. NVMe SSDs should comfortably exceed 20,000 IOPS at 4k random. If you see under 2,000, the disk is either heavily shared or backed by slower storage.

5. Network throughput

# Speed to a nearby public test server
curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python3 -

# Or download a known-good test file
curl -o /dev/null http://speedtest.tele2.net/1GB.zip

Compare against the advertised port speed. A "1 Gbps port" should sustain 700+ Mbps to a well-peered endpoint. Anything under 200 Mbps is suspicious for a 1 Gbps plan.

6. Latency and routing

# Latency to common anchors
ping -c 10 1.1.1.1
ping -c 10 8.8.8.8

# Route quality from your VPS to your audience
mtr -rwzbc 50 your-audience-region.example.com

If you're hosting for European users, latency from a US-East VPS will be 80–120 ms minimum and that's physics, not the provider's fault. Use mtr to spot bad hops — sustained packet loss on an intermediate hop is a routing problem worth opening a ticket for.

7. Uptime and stability

# Has the VPS rebooted unexpectedly?
uptime
last reboot | head

# Kernel messages — OOM kills, disk errors, network resets
dmesg -T | tail -100
journalctl -p err -b

An honest provider's VPS should run for weeks without unexplained reboots. OOM kills mean you're undersized; disk errors mean you should open a ticket.

8. All-in-one benchmark

yabs.sh bundles most of the above into a single report. Read the script first if you care about supply chain, then:

curl -sL yabs.sh | bash

Save the output. It's the cleanest single artifact to attach to a support ticket or to compare across providers later.

FAQ