Benchmark Linux systems with sysbench

In this blog post, I will show how to use sysbench to test the CPU, memory and storage performance of a Linux system. I also had the chance to access some diverse hardware (laptop, desktop, servers). So I’ll also give some results for you to compare with.

The platforms that I will benchmark are:

• a recent laptop with a mobile Intel processor and SSD;
• a desktop computer with Intel processor and SSD;
• an old server equipped with 4 Xeon processors, RAID controller and spinning disks;
• a server with AMD CPU, RAID controller and an array of SSD.

Update June 2024 : I added a VirtualBox VM to the comparison.

Installation

You can usually install sysbench with:

sudo apt install sysbench

CPU

Single thread

You can run sybench cpu test with:

sysbench cpu run

The result is expressed in “events per second” (4040 in the example below):

Multi-thread

By default, sysbench runs cpu test with a single thread. To test multi-thread performance of your CPU, you should first determine the number of available threads:

grep processor /proc/cpuinfo | wc -l

Then you can run sysbench again, specifying the number of threads:

sysbench cpu run --threads=<threads>

Results

Memory

Now, you can measure the speed of your memory with

sysbench memory run

The result is the measure transfer speed, expressed in MiB/sec.

If you want to compare your results with mine, you can also check the type and speed of your installed memory with:

sudo dmidecode --type 17

Results

Storage

You can also use sysbench to test the performance of you storage devices. This is a little more subtle for different reasons:

1. storage benchmarking requires to first create some test files;
2. SSD and RAID cards have a built-in controller with cache that will largely influence the results;
3. the default test parameters of sysbench do not reflect real-life utilization of storage devices.

So the first thing to do is to create files that will be used for testing:

sysbench fileio --file-total-size=5G --file-num=5 prepare

As mentioned above, I will use additional parameters to run the test. This will be more representative of actual usage, and allows the controller and cache to be used during the test:

• run the test in async mode;
• synchronize storage only once at the end of the test;
• for sequential access test, use larger 1MB blocks;
• for random access test, use smaller 4KB blocks.

To test random storage access:

sysbench fileio --file-total-size=5G --file-num=5 --file-io-mode=async --file-fsync-freq=0 --file-test-mode=rndrd --file-block-size=4k run
sysbench fileio --file-total-size=5G --file-num=5 --file-io-mode=async --file-fsync-freq=0 --file-test-mode=rndwr --file-block-size=4k run

To test sequential access:

sysbench fileio --file-total-size=5G --file-num=5 --file-io-mode=async --file-fsync-freq=0 --file-test-mode=seqrd --file-block-size=1M run
sysbench fileio --file-total-size=5G --file-num=5 --file-io-mode=async --file-fsync-freq=0 --file-test-mode=seqwr --file-block-size=1M run

Results

Also, note that you can use the following command line to check the type of storage on your system:

sudo lshw -class disk -class storage

VirtualBox VM

To add some elements of comparison, I deployed a VirtualBox VM on Server 2. The VM has 4 cores, 4GB of RAM, and a single VDI disk. Here are the results I got, compared with the results of the host server:

As one could expect, there is a small penalty of using a VM with respect to CPU and memory. The storage penalty however is staggering: 90% of performance drop!

I double checked on an other server and came to the same conclusion: using a virtual disk causes a performance drop of roughly 90%.

This blog post is licensed under CC BY-SA 4.0