Benchmark CPU, memory, disks and network

Benchmarks are only useful when they are repeatable. This guide gives a short method and exact commands for CPU, memory, disks and network, so you can check a new server, compare two machines fairly or spot a problem. We do not publish benchmark scores for our servers: these commands let you measure yours.

Method: make results comparable

• Test an idle system. Stop your applications and check with top that nothing else uses CPU or disk. After a fresh install, wait until the initial RAID sync has finished: cat /proc/mdstat must show no resync or recovery in progress.
• Run each test three times and keep the median. If runs differ a lot, find out why before trusting any number.
• Write down the context: CPU model (lscpu), kernel (uname -r), OS release, tool versions, file system, RAID layout and the exact command line.
• Compare like with like: same OS, kernel, tool version and parameters on both machines. A different thread count, block size or queue depth makes two results incomparable.

Install the tools on Ubuntu or Debian:

apt install -y sysbench p7zip-full fio iperf3

On AlmaLinux or Rocky Linux, sysbench and 7-Zip come from EPEL:

dnf install -y epel-release
dnf install -y sysbench p7zip-plugins fio iperf3

CPU: sysbench and 7-Zip

sysbench cpu --threads=1 --time=30 run
sysbench cpu --threads=$(nproc) --time=30 run

Compare events per second. The single-thread result reflects per-core speed, which most game servers and many web requests depend on. The multi-thread result shows total throughput for builds, rendering and virtualization. This test computes prime numbers inside the CPU cache, so it says little about memory or real applications.

7z b
7z b -mmt1

7-Zip’s built-in benchmark rates compression and decompression in MIPS; use the Tot: line, which combines both. -mmt1 limits it to one thread.

Memory: sysbench

sysbench memory --threads=1 --memory-block-size=1M --memory-total-size=100G run
sysbench memory --threads=$(nproc) --memory-block-size=1M --memory-total-size=100G run

Read the MiB/sec line. Add --memory-oper=read to measure reads instead of writes. Multi-thread bandwidth depends heavily on the number of memory channels: an 8- or 12-channel EPYC platform scales much further than a dual-channel desktop platform.

Disks: fio

Each command runs for 60 seconds after a 5-second ramp, bypasses the page cache (--direct=1) and uses an 8 GB test file:

fio --name=seq-read --filename=/var/tmp/fio.test --size=8G --rw=read --bs=1M --ioengine=libaio --iodepth=16 --numjobs=1 --direct=1 --runtime=60 --time_based --ramp_time=5 --group_reporting
fio --name=seq-write --filename=/var/tmp/fio.test --size=8G --rw=write --bs=1M --ioengine=libaio --iodepth=16 --numjobs=1 --direct=1 --runtime=60 --time_based --ramp_time=5 --group_reporting
fio --name=rand-read --filename=/var/tmp/fio.test --size=8G --rw=randread --bs=4k --ioengine=libaio --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_based --ramp_time=5 --group_reporting
fio --name=rand-write --filename=/var/tmp/fio.test --size=8G --rw=randwrite --bs=4k --ioengine=libaio --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_based --ramp_time=5 --group_reporting
rm /var/tmp/fio.test

• Sequential 1M results are bandwidth (BW=): what matters for backups, media and large files.
• Random 4k results are IOPS: what matters for databases and virtual machines. Also read the clat percentiles: the 99th and 99.9th percentiles say more than the average about interactive workloads.
• RAID 1 can serve reads from both disks, so parallel random reads may exceed one disk, while every write goes to both.
• SSD write caches: many SSDs absorb writes in a fast cache and slow down once it is full. A longer run (--runtime=300) shows the sustained speed.
• ZFS caches data in RAM, which can inflate read results: use a test file larger than RAM, or benchmark your real application.

--ioengine=io_uring is a good alternative to libaio on current kernels; use the same engine on every machine you compare.

Network: iperf3

iperf3 measures throughput between two machines you control. Start a server on one end, open TCP port 5201 in its firewall for the test, and stop it with Ctrl+C when you are done:

iperf3 -s

On the other machine, test both directions (-R reverses the direction):

iperf3 -c 203.0.113.10 -P 4 -t 30
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

With a standard 1500-byte MTU, TCP payload tops out around 940 Mbit/s on a 1 Gbps port and around 9.4 Gbit/s on 10 Gbps; use more streams (-P 8) on 10 Gbps. Results are also limited by the other end, the distance and every network in between: test towards a server in the same region to measure the port, and towards your users to measure the path. For latency and route checks, see network testing.

Interpret and compare results

• Match the test to the workload: single-thread CPU and latency for game servers, random 4k IOPS and latency for databases, multi-thread CPU and memory bandwidth for builds and virtualization.
• Finish with your own application. Synthetic tests isolate one component; a load test of the real service, for example pgbench for PostgreSQL, answers the question you actually care about.
• Compare fairly: same commands, same OS and kernel, idle systems, three runs each. The hardware of every plan is listed on Compare servers.
• Investigate outliers. A result far below similar hardware can point to throttling or a hardware fault: check disk health and temperatures first.

Next steps

• Check the path to your users with mtr and iperf3.
• Need more cores or faster storage? Compare Performance and Enterprise servers.
• Results far below what the hardware should do? Send your commands and outputs to support.