Sysbench

From wiki.mikejung.biz
Jump to: navigation, search

Liquidweb high performance banner.gif

Contents

Sysbench

Sysbench is one of a few other Benchmarking utilities that can be used to test out VPS and Cloud Server performance. Sysbench is one of the most common benchmarking utilities, so it's easy to find and compare performance results since a lot of people use Sysbench and similar tests.

Sysbench allows you to test out performance in the following areas:

  • CPU -- This is a CPU performance test which uses a maximum prime number value that's defined when the test is run to determine how long it takes the system to calculate the numbers. You can specify how many threads to use for this test, making it a quick and easy way to test CPU performance for various amounts of threads.
  • OLTP -- This is a Database / MySQL performance test which helps to estimate best case scenario MySQL performance. You can simulate read only workloads, by only using SELECT queries, or you can test mixed read and write environments. Almost anyone who writes about MySQL performance uses Sysbench OLTP for performance tests and results.
  • fileio -- This is your disk IO test. Similar to FIO, but much less complex in terms of output and options. You can test sequential reads and writes, as well as random reads and writes. Sysbench fileio allows you to modify block size for IO, and the ability to toggle direct io, sync, async, and various other IO related functions.

Installing Sysbench

You can install Sysbench via apt-get, yum, or .rpm / .deb packages. You can also install Sysbench from source, either way installing Sysbench is usually pretty simple. The latest version of Sysbench in 0.5 however the most popular version is 0.4.12. There are some slight performance differences between 0.4.12 and 0.5, specifically with the OLTP test, Sysbench 0.5 tends to provide slightly lower results, this may change in the future, but if you are comparing Sysbench 0.4.12 results to Sysbench 0.5 results, make sure you run some additional tests to verify the results are correct.

Sysbench 0.4.12 Source Install On CentOS 6.5 and CentOS 6.6

wget the source files for Sysbench, unzip the tar.gz file, then install the dependencies needed for Sysbench. This should work on most Redhat / CentOS based systems.

wget http://pkgs.fedoraproject.org/repo/pkgs/sysbench/sysbench-0.4.12.tar.gz/3a6d54fdd3fe002328e4458206392b9d/sysbench-0.4.12.tar.gz
tar zxvf sysbench-0.4.12.tar.gz
yum install libtool.x86_64 openssl-devel.x86_64 openssl-static.x86_64
cd sysbench-0.4.12/
libtoolize --force --copy
./autogen.sh
./configure
make
make install

/usr/bin/ld: cannot find -lssl If you see this error, make sure that you have the openssl-devel and openssl-static packages installed.

Install Sysbench 0.4.12 via RPM on CentOS 6.6

To install Sysbench 0.4.12 on CentOS 6.x or Redhat you can wget the latest remi and epel repos, install them, then install sysbench.

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
rpm -Uvh remi-release-6*.rpm epel-release-6*.rpm
yum install sysbench

Install Sysbench 0.5 via YUM on CentOS 6.7

This may also work with CentOS 6.{1,6}, but only 6.7 has been tested.

Install the Percona Repo and install sysbench:

wget https://www.percona.com/redir/downloads/percona-release/redhat/latest/percona-release-0.1-4.noarch.rpm
rpm -Uvh percona-release-0.1-4.noarch.rpm
yum install sysbench

Install Sysbench 0.4.12 via YUM on CentOS 7.1

It's available in the epel repo.

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install sysbench

Install Sysbench 0.5 via YUM on CentOS 7.3

You need to install the latest Percona repo to install Sysbench 0.5 if you use EPEL you will install version 0.4.12. Sysbench version 0.5 allows you to do LUA scripting and create multiple tables to run the OLTP test against.

wget https://www.percona.com/redir/downloads/percona-release/redhat/latest/percona-release-0.1-4.noarch.rpm
rpm -Uvh percona-release-0.1-4.noarch.rpm
yum install sysbench

Install Sysbench 0.4.12 on Ubuntu 14.04 and 14.10

If you want to stick with the slightly older 0.4.12 Sysbench you can easily install it on most modern Debian based distros by simply apt-get installing sysbench.

apt-get install sysbench

Install Sysbench 0.5 via Percona Repo on Ubuntu 14.04

Percona includes the latest version of sysbench in their repos, and if you care about performance, chances are you are using Percona, if not, then you may not want to install it this way.

echo "deb http://repo.percona.com/apt trusty main" >> /etc/apt/sources.list.d/percona.list
echo "deb-src http://repo.percona.com/apt trusty main" >> /etc/apt/sources.list.d/percona.list
apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
apt-get update
apt-get install sysbench

Old Methods

Steps detailed in this section are either outdated or broken.

Install Sysbench on CentOS 7

This should work ok for CentOS 7, verified it does indeed install sysbench 0.4.12

wget ftp://ftp.gnome.org/mirror/fedora/epel/6/x86_64/sysbench-0.4.12-5.el6.x86_64.rpm
wget http://downloads.mysql.com/archives/mysql-5.1/MySQL-shared-compat-5.1.49-1.rhel5.x86_64.rpm
rpm -iv MySQL-shared-compat-5.1.49-1.rhel5.x86_64.rpm
yum install postgresql-libs.x86_64
rpm -iv sysbench-0.4.12-5.el6.x86_64.rpm

Sysbench OLTP / MySQL Tests

Creating a test database with Sysbench

Assuming you have Sysbench installed, you can just login to MySQL if you don't save the root mysql password in /root/.my.cnf then you will need to use mysql -p and enter in the root mysql password. Create a new database and user to use as the test database, generally I just use sysbench for the user and the db and stick with a simple password since I am only testing on a temporary server. Make sure you replace my weak password with an actual secure password, otherwise you could get compromised in a hurry especially if you configure MySQL to listen on a public IP

##Create Database 
mysql -u root -ppassword -e "CREATE DATABASE sysbench;"

##Create User
mysql -u root -ppassword -e "CREATE USER 'sysbench'@'localhost' IDENTIFIED BY 'password';"

##Grant Access 
mysql -u root -ppassword -e "GRANT ALL PRIVILEGES ON *.* TO 'sysbench'@'localhost' IDENTIFIED  BY 'password';"

Once you have created the test database and user, run the command below to fill up the database with some data. If you use an oltp table size of 10000000, sysbench will create a database that is about 2GB in size. If you double the table size to 20000000 the database will be around 4GB in size. I recommend creating a test database that is close to the size of databases that you normally see in production.

sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password prepare

Read Only OLTP tests

This command will run a Read-Only Sysbench OLTP test without the "BEGIN" statement. I like to run OLTP tests at various thread levels to get an idea of how MySQL will perform under certain workloads. This test will start off running a single threaded OLTP read only test, sleep for 10 seconds, then run a 4 threaded OLTP read only test, and will continue to do that until the 64 threaded test has finished. If you only have a few CPUs you may not need to run 64 threaded tests.

for each in 1 4 8 16 32 64; do sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=$password --max-time=240 --max-requests=0 --oltp-read-only --oltp-skip-trx  --oltp-nontrx-mode=select --num-threads=$each run; sleep 10; done


Similar to the test above, this is also a Read-Only Sysbench OLTP test, but without the extra options.

for each in 1 4 8 16 32 64; do sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --max-time=240 --oltp-read-only=on --max-requests=0 --num-threads=$each run; sleep 10; done

Mixed Read and Write OLTP tests

Read and Write OLTP Mixed Test. Usually about 70% read (select) and 30% write (insert, update, delete)

sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --max-requests=0 run

Read and Write OLTP test with 16 threaded and random connection mode

sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --max-requests=0 --num-threads=16 --oltp-reconnect-mode=random run

Simple Sysbench OLTP Test Script for Ubuntu and Debian

Make sure the system is updated. Then simply install Sysbench, and MySQL Server if you plan on running OLTP tests.

apt-get update
apt-get install -y sysbench
apt-get install -y mysql-server
sysbench --test=fileio --file-total-size=4G --file-num=64 prepare

mysql -u root -ppassword -e "CREATE DATABASE sysbench;"
mysql -u root -ppassword -e "CREATE USER 'sysbench'@'localhost' IDENTIFIED BY 'password';"
mysql -u root -ppassword -e "GRANT ALL PRIVILEGES ON *.* TO 'sysbench'@'localhost' IDENTIFIED  BY 'password';"
sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password prepare


You can then run this script which will run each test 3 times at each thread level listed. This can help to find the "sweet spot" in terms of performance.

#!/bin/bash

for run in 1 2 3 ;do
for thread in 1 4 8 16 32 ;do

echo "Performing test RW-${thread}T-${run}"
sysbench --test=fileio --file-total-size=4G --file-test-mode=rndwr --max-time=60 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=${thread} run > /root/RW-${thread}T-${run}

echo "Performing test RR-${thread}T-${run}"
sysbench --test=fileio --file-total-size=4G --file-test-mode=rndrd --max-time=60 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=${thread} run > /root/RR-${thread}T-${run}

echo "Performing test SQ-${thread}T-${run}"
sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --max-time=60 --max-requests=0 --num-threads=${thread} run > /root/SQ-${thread}T-${run}

done
done


Sysbench 0.5 OLTP Read and Write Test

This script will run 6 tests, each lasting 4 minutes. It will run 1 through 64 threaded tests, which seem to be the most common tests to run. This test does selects, updates, and various other things and is considered to be a "read / write" MySQL mixed workload.

for each in 1 4 8 16 32 64; do sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=20000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --max-time=240 --max-requests=0 --num-threads=$each run; done

Sysbench 0.5 OLTP Read Only Test

This script will run 6 tests, each lasting 4 minutes. It will run 1 through 64 threaded tests, which seem to be the most common tests to run. This runs selects only, and is considered to be "read only".

for each in 1 4 8 16 32 64; do sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua --oltp-table-size=20000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --oltp-read-only=on --max-time=240 --max-requests=0 --num-threads=$each run; done

Test Script

Prepare the server

apt-get update
apt-get install -y sysbench 
apt-get install -y mysql-server
sysbench --test=fileio --file-total-size=4G --file-num=64 prepare

mysql -u root -ppassword -e "CREATE DATABASE sysbench;"
mysql -u root -ppassword -e "CREATE USER 'sysbench'@'localhost' IDENTIFIED BY 'password';"
mysql -u root -ppassword -e "GRANT ALL PRIVILEGES ON *.* TO 'sysbench'@'localhost' IDENTIFIED  BY 'password';"
sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password prepare


#!/bin/bash

for run in 1 2 3 ;do
for thread in 1 4 8 16 32 ;do

echo "Performing test RW-${thread}T-${run}"
sysbench --test=fileio --file-total-size=4G --file-test-mode=rndwr --max-time=60 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=${thread} run > /root/RW-${thread}T-${run}

echo "Performing test RR-${thread}T-${run}"
sysbench --test=fileio --file-total-size=4G --file-test-mode=rndrd --max-time=60 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=${thread} run > /root/RR-${thread}T-${run}

echo "Performing test SQ-${thread}T-${run}"
sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --max-time=60 --max-requests=0 --num-threads=${thread} run > /root/SQ-${thread}T-${run}

done
done

Various Tests

Disk Tests

##The size of the file depends on the amount of RAM in the system, so if you have 32GB RAM installed, the test file needs to be larger than 32GB
sysbench --test=fileio --file-total-size=60G --file-num=64 prepare

##Random Write using no fsync (Should show the highest potential random writes)
sysbench --test=fileio --file-total-size=60G --file-test-mode=rndwr --max-time=720 --max-requests=0 --num-threads=8 --file-num=64 --file-io-mode=async --file-extra-flags=direct --file-fsync-freq=0 run

##Random Write using default fsync (Should show typical fsync behavior)
sysbench --test=fileio --file-total-size=60G --file-test-mode=rndwr --max-time=720 --max-requests=0 --num-threads=8 --file-num=64 --file-io-mode=async --file-extra-flags=direct --file-fsync-freq=0 run


##Random Read Only
sysbench --test=fileio --file-total-size=20G --file-test-mode=rndrd --max-time=240 --max-requests=0 --num-threads=${1,8,64} run

##Mixed Random Read and Write
sysbench --test=fileio --file-total-size=20G --file-test-mode=rndrw --max-time=240 --file-fsync-all --max-requests=0 --num-threads=${1,8,64} run


###For Loops

###RAND WRITE 1 - 16 thread
for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run; done; sleep 10; for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=4 run; done; sleep 10; for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=8 run; done; sleep 10; for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=16 run; done;

###RAND READ 1 - 16 thread
for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run; done; sleep 10;for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=4 run; done; sleep 10;for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=8 run; done; sleep 10;for each in {1..3} ; do sysbench --test=fileio --file-total-size=5G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=16 run; done; sleep 10;

CPU Tests

##This test defaults to using 1 thread, good to run with one thread, then 32 or whatever
sysbench --test=cpu --cpu-max-prime=20000 run

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=32 run

RAM Tests

sysbench --test=memory --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read run

sysbench --test=memory --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write run

Using OLTP with custom .lua scripts

##Install and move to the db test directory##
wget wget http://www.lefred.be/files/sysbench-0.5-3.el6_.x86_64.rpm
rpm -iv sysbench-0.5-3.el6_.x86_64.rpm
cd /usr/share/doc/sysbench/tests/db

##Prepare a test table on the target system##
sysbench --test=parallel_prepare.lua --oltp-table-size=10000000 --mysql-host=$remote_host --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --oltp-tables-count=1 --num-threads=32 prepare

##Run Tests based off of .lua##
sysbench --test=oltp_simple.lua --oltp-table-size=10000000 --mysql-host=$remote_host --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --oltp-read-only=on --oltp-skip-trx=on    --max-time=120 --max-requests=0 --max-time=120 --num-threads=512 run


MySQL Tests

##Create Database 
CREATE DATABASE sysbench;

##Create User
CREATE USER 'sysbench'@'localhost' IDENTIFIED BY '$password';

##Grant Access 
GRANT ALL PRIVILEGES ON *.* TO 'sysbench'@'localhost' IDENTIFIED  BY '$password';

##Prepare a test table
sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password prepare

##Read-Only Test without "BEGIN"
sysbench --db-driver=mysql --test=oltp --oltp-table-size=10000000 --mysql-host=$IP --mysql-db=sysbench --mysql-user=sysbench --mysql-password=$password --max-time=120 --max-requests=0 --oltp-read-only --oltp-skip-trx  --oltp-nontrx-mode=select --num-threads=256 run

##Read-Only Test
sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run

##Mixed Test
sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --max-requests=0 run

##Mixed Test 8 threads
sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --max-requests=0 --num-threads=8 run

##16 threads, Random connect / disconnect for threads
sysbench --test=oltp --oltp-table-size=10000000 --mysql-db=sysbench --mysql-user=root --mysql-password=password --max-time=60 --max-requests=0 --num-threads=16 --oltp-reconnect-mode=random run
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/common.lua-20110427224028-j1y84gokmt93n8xn-1/common.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/sysbenchtestsdbinser-20090113060453-687cibzqa6u5f1i4-115/insert.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/oltp.lua-20110427224028-j1y84gokmt93n8xn-2/oltp.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/sysbenchtestsdboltp_-20090113060453-687cibzqa6u5f1i4-118/oltp_simple.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/sysbenchtestsdbselec-20090113060453-687cibzqa6u5f1i4-119/select.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/select_random_points-20101028165209-ue1iedn6sn5azlvx-1/select_random_points.lua
wget http://bazaar.launchpad.net/~vadim-tk/sysbench/sysbench-db-scripts/download/head:/select_random_ranges-20101028165209-ue1iedn6sn5azlvx-2/select_random_ranges.lua

Sysbench CPU Tests

To run a single threaded CPU test, run the following command. Generally speaking it's a good idea to run a single threaded sysbench CPU test, as well as another rest with threads equaling the amount of CPUs the server has. If it has 4 cores and 8 threads then I suggest running a single threaded test, 4 threads, and 8 threads to get an idea of how threaded process scales for your server.

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

To run a 4 threaded Sysbench CPU test, use this command.

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run

You can use the script below to run multi threaded Sysbench CPU tests

for each in 1 2 4 8 16 32 64; do sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$each run; done

The lower the result, the faster the CPU. Multithreaded CPUs will not show their true performance unless you run the test with the correct amount of threads. If you have an 8 core CPU you should run an 8 thread CPU test to get the true performance number.

Cloud / VPS CPU Performance Test Results with Sysbench

If you only have a single CPU server, there is not any point in CPU tests above your core count as performance won't scale past the amount of CPUs you have. This is not the case with IO and OLTP tests which usually scale to a thread count of 2 x server CPU

Below are some example results using 1 and 2 threaded Sysbench CPU tests. Both of these servers are virtualized instances. Azure instance is using HyperV for the hypervisor and the LiquidWeb VPS server is using KVM for the hypervisor. As you can see, since the Azure VPS only has a single vCPU the performance between the 1 and 2 threaded tests are basically the same. With the LiquidWeb VPS performance scaled as expected between the 1 and 2 threaded test.

This is why it's important to test out multiple threaded CPU tests since not all vps or cloud vps servers are the same in terms of vCPU count and CPU utilization limits. As you can see here, the LiquidWeb 1GB SSD VPS]is almost 4 times faster than the Azure A1 instance in terms of CPU performance. Again, lower times are better, longer test times means slower. The vps CPU performance results are not surprising. LiquidWeb's VPS has 2 E3-1270 vCPUs which are much newer and faster than Azure's AMD Opteron.

  • Azure A1 Standard with 1 vCPU (AMD Opteron 4171 HE @ 2.1GHz) (Tested on 01-12-2015)
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

1 thread 49.3510s

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run

2 thread 49.7294s
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

1 thread 24.3093s

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run

2 thread 13.2732s
  • Digital Ocean 1GB VPS with 1 vCPU (E5-2630L) (Tested on 10-13-2014)
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

1 thread 35.69s

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run

2 thread 35.32s
  • Rackspace 1GB Standard VPS 1 vCPU (E5-2670v1) (Tested on 10-13-2014)
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

1 thread 28.85s

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run

2 thread 28.87s
  • AWS t2.micro 1 vCPU (E5-2670v2) (Tested on 10-13-2014)
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

1 thread 26.77s

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run

2 thread 26.73s

As you can see, CPU performance can be all over the place, especially with VPS and Cloud servers, which are often times sharing the same CPU with many other instances. If you notice a large variation in CPU performance between CPU test runs then you may be on a server with lots of "noisy neighbors" who are also using lots of CPU.

As you can see, LiquidWeb VPS has the fastest CPU for 1 and 2 threaded CPU performance. AWS come in a close second with Rackspace slightly behind, but only with single threaded performance. The 1GB LiquidWeb VPS was two times faster than AWS and Rackspace for 2 threaded CPU performance, at least for the 1GB VPS tier. Hardware changes often, so these tests are meant to be an example of what Sysbench can tell you about performance. Please test CPU performance and see for yourself!


You can use the script below to run multi threaded Sysbench CPU tests. If you want to run a more demanding test, modify the cpu max prime value to a larger number, such as 80000 or higher. The higher this value is the longer the tests take to complete. Typically with a value of 20000, single threaded tests can take anywhere from 20 seconds to a minute or more. The shorter the time, the better the result, so faster CPUs will take less time to run the test.

for each in 1 2 4 8 16; do sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$each run; done

The lower the result, the faster the CPU. Multithreaded CPUs will not show their true performance unless you run the test with the correct amount of threads. If you have an 8 core CPU you should run an 8 thread CPU test to get the true performance number.

Sysbench Fileio Options

Sysbench Fileio file-extra-flags

This option allows you to change the flags used when sysbench performs the open syscall. This option can be helpful if you want to test the difference between using caching / buffering as much as possible, or avoiding caching / buffers as much as possible.

--file-extra-flags=$VALUE
  • O_DIRECT will minimize cache effects of IO to, and from the file being used. This can sometimes lower performance, but in some cases it can actually improve application performance if the application has it's own cache. File IO is done directly to / from the user space buffers. When O_DIRECT is specified on it's own it will try to transfer data synchronously, however it won't guarantee that data and it's metadata are transferred, like O_SYNC. You should use O_SYNC in addition to O_DIRECT if you want to be damn sure data is always safely written.
  • O_DSYNC Similar to O_DIRECT, however this ensures that all data are written to disk before considering the write complete. Basically with this mode, each write is followed by fdatasync. This is slightly less safe than O_SYNC which is like a write followed by fsync, this ensure the data is written AND the metadata is written.
  • O_SYNC This mode is similar to O_DSYNC, which ensures data integrity. O_SYNC provides file integrity as well as data integrity. This means the file data and metadata are both guaranteed to complete and be written to disk.

You should add this argument at the very end of the sysbench command, but before "run" at the very end.

--file-extra-flags=direct
--file-extra-flags=O_DIRECT
--file-extra-flags=O_DSYNC
--file-extra-flags=O_SYNC

For example, you can run a random write test with "--file-extra-flags=direct" by running the command below

sysbench --test=fileio --file-total-size=8G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --num-threads=$each --file-extra-flags=direct run

Sysbench Fileio file-io-mode

This option allows you to choose which IO mode sysbench should use for IO tests. By default this is set to sync. Depending on the OS you can change this to async. This is useful to test out performance differences between sync and async, typically async will be faster if your version of Linux supports it.

--file-io-mode=$value

Possible values are

--file-io-mode=sync
--file-io-mode=async
--file-io-mode=fastmmap
--file-io-mode=slowmmap

Sysbench Fileio file-block-size

This value defines the block size that should be used for the IO tests. By default sysbench sets this to 16K (KB), if you want to test random io then usually 4K should be used, if you are testing out sequential IO then larger blocksizes of 1M should be used.

--file-block-size=$Number

You can configure the blocksize to be whatever you want, the most common sizes are listed below. The smaller the block size, the slower the IO is. The larger the block size the more throughput you get.

--file-block-size=4K
--file-block-size=16K
--file-block-size=1M

Sysbench Fileio file-num

This option allows you to specify the amount of files to use for the IO test. The default value is 128 files, so if you have a file test size of 128GB each of the 128 files created would be 1GB in size. You can adjust this to whatever value you want, so if your application typically writes to say, 100 files then you can set the number to 100

--file-num=$number

Valid options for this flag are positive numbers

--file-num=1
--file-num=64
--file-num=128
etc etc

Sysbench Fileio file-fsync-all

This option does not have any additional flags, If you add this to a random write test then each write will be flushed to disk using fsync before moving on to the next write. This option allows you to see how IO performs under the most "extreme" case, meaning an application that must ensure every single transaction / write is safely written on disk instead of just placed in a buffer to be written out later. Performance will be much lower when using this option.

--file-fsync-all

These are the valid options for file-fsync-all

--file-fsync-all

If you do not add this option then sysbench will use the default fsync option which flushes writes to disk after 100 writes are performed.

Sysbench Fileio file-test-mode

You can select which test sysbench will run by changing the value for file-test-mode

--file-test-mode=$MODE

These are the valid options for file-test-mode

--file-test-mode=seqwr (sequential write test)
--file-test-mode=seqrd (sequential read test)
--file-test-mode=rndwr (random write test)
--file-test-mode=rndrd (random read test)
--file-test-mode=rndrw (random read and write test)

Sysbench Fileio Tests

First prepare files to use for the test, you can change the size to whatever you want, here I am using 8GB file size, with 64 files total.

sysbench --test=fileio --file-total-size=8G --file-num=64 prepare

This will run 1 - 64 threaded IO tests for random read, random write with default fsync which means data is flushed to disk ever 100 write requests. I am also testing random writes with fsync all which means that after each write data is flushed to disk. I like to run both random write tests because the first is more "real world" the second is much harsher, but for servers / applications that ensure every write is safe, the fsync all IO test is a good way to get a general idea of IO performance.

for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=8G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=$each run; sleep 10; done; for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=8G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --file-fsync-all --num-threads=$each run; sleep 10; done; for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=8G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=$each run; sleep 10; done

Sysbench Prepare

Generally, I like to create / prepare test files before I run the read and write tests. To prepare test files, run the command below. Typically I will prepare a test file with a size that is about two times more than the amount of RAM the server has. If it's a 2GB vps then I'll use a 4GB file size, if it's a 1GB vps then I'll use 2GB file size. I do this so that the ratio between file size and RAM is always roughly the same. You can force direct io to get around inflated cached results, but if you always use a test file thats 2 times larger than RAM you will avoid having all reads come from the cache in RAM which will give you super inflated results. If you notice very high numbers for IO tests odds are you need to flush caches and buffers before testing IO again.

sysbench --test=fileio --file-total-size=2G --file-num=64 prepare
  • file-total-size Can be adjusted to whatever size you want. You can use M for Megabytes as well. I like to use a file size of at least 2 times the amount of RAM that the box has.
  • file-num Can be adjusted as well. The default is 128. but you can raise or lower this value to more closely match your workload.

Sysbench Random Write Test

Below is a basic Sysbench random write test. This test uses a file size of 2GB, and will run for a maximum of 240 seconds before finishing. For larger tests you might want to enforce a max time so that the tests do not run for hours and hours. The example below is only running a singled threaded test. Typically, the higher you set num-threads the faster the result will be. However, this is only true up to a point, usually performance will start to cap out once you reach a thread count that is 2 x the number of CPUs on the test system. I suggest doubling the amount of threads to use for random read or write tests until you hit the "cap" in terms of performance. If you only run a single threaded random read test on an SSD you will get lower performance results than if you used 16 threads for the test. Usually SSDs cap out around 64 threads, but faster PCIe Flash devices scale up to 128 or even 256 threads if you have a fast enough CPU to handle the IO.

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run

Make sure you change file-total-size to match whatever size you used to prepare the sysbench files, again, I like to use a file test size of roughly 2 x the amount of VPS RAM to avoid having all reads come from the cache. Write speed can also be effected by the file size as well, so you can get somewhat inflated results if you write a 2GB file on a server with 16GB of ram since a lot of the writes will hit the buffer before hitting the disk, while this is normal behavior it does not isolate the underlying block device's performance unless you use direct io flags, or use a file size that is large enough to not fit into RAM.

I prefer to run the script below, which will run the same random write test multiple times. This test will run 1, 4, 8, 16, 32, and 64 threaded random write tests.

for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=2G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=$each run; sleep 10; done

Sysbench Random Read Test

Below is a basic Sysbench random read test. This test uses a file size of 2GB, and will run for a maximum of 240 seconds before finishing. For larger tests you might want to enforce a max time so that the tests do not run for hours and hours. The example below is only running a singled threaded test. Typically, the higher you set num-threads the faster the result will be. However, this is only true up to a point, usually performance will start to cap out once you reach a thread count that is 2 x the number of CPUs on the test system.

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run

Make sure you change file-total-size to match whatever size you used to prepare the sysbench files, again, I like to use a file test size of roughly 2 x the amount of VPS RAM to avoid having all reads come from the cache. Write speed can also be effected by the file size as well, so you can get somewhat inflated results if you write a 2GB file on a server with 16GB of ram since a lot of the writes will hit the buffer before hitting the disk, while this is normal behavior it does not isolate the underlying block device's performance unless you use direct io flags, or use a file size that is large enough to not fit into RAM.


I prefer to run the script below, which will run the same random read test multiple times. This test will run 1, 4, 8, 16, 32, and 64 threaded random read file io tests.

for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=$each run; sleep 10; done

VPS and Cloud Server Random Write Performance Tests Using Sysbench

Generally I like to prepare a set of files to use for random read, or write tests. For random write tests you could potentially skip the prepare step, but if you are going to run read and write tests you might as well just prepare the test files first. I'm testing out 1GB VPS performance, so I am using a test file size of roughly twice the amount VPS RAM. I do this to avoid the possibility of Linux caching all the data in RAM, at least this way the ratio between file size and RAM is always 2:1 to avoid all reads coming from RAM. I don't want to entirely eliminate caching effects, just reduce them to a more realistic scenario. If you don't think 2:1 is a good ratio then feel free to adjust the file size to whatever you want, this is just an example.

sysbench --test=fileio --file-total-size=2G --file-num=64 prepare

This is one of the more simple random write tests. The test runs for 240 seconds, or 4 minutes, uses a block size of 4KB, using 64 files that are 32MB in size each. By default Sysbench will use FSYNC after every 100 requests. Syncronous I/O mode is used by default unless you specify async, but that is not supported on all OSs.

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run

This is what the test result will look like once the test is done. I've removed some of the output to make it easier to display the results as well as to focus on the results that really matter. The results below were collected from LiquidWeb's 1GB SSD VPS

Operations performed:  0 Read, 2242700 Write, 1435295 Other = 3677995 Total
Read 0b  Written 8.5552Gb  Total transferred 8.5552Gb  (36.502Mb/sec)
 9344.54 Requests/sec executed

Test execution summary:
    total time:                          240.0010s
    total number of events:              2242700
    total time taken by event execution: 10.4937
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  8.28ms
         approx.  95 percentile:               0.01ms

The most important information to look at from these results are

  • Requests/sec executed: 9344.54

Requests/s executed is more or less IOPS or input / output operations per second. In this case it means that the 1GB LiquidWeb SSD VPS is able to perform 9,344(iops) 4KB write operations per second. Some people prefer to view performance in MB/s or even GB/s. Sysbench displays both results (36.502Mb/sec) is roughly equal to 4KB x 9344 = 37376KB/s or about 36MB/s. IOPS is much more useful to know, but you must also include the block size used or else the results will be meaningless. A 4KB IOP is not equal to a 16KB IOP. Often times people will use 16KB or 1MB block sizes for random write tests which will inflate results because each IOP is transferring more data, so the throughput is higher.

Most of the time you will be dealing with 4KB block sizes so if you are testing random write performance you should really stick with 4KB unless your environment deals with different block sizes.

  • approx. 95 percentile: 0.01ms

IOPS only tells you so much about performance, to get a full picture of IO performance you want to look at the 95% response time as well. This number tells you what 95% of of response times looks like. This is a much more useful metric than "average" or "minimum" response times. Maximum response time is another good metric, but most benchmarking sites and results typically show IOPS and 95% response times.

In the example above, the LiquidWeb 1GB SSD VPS had a 95% response time of 0.01ms (milliseconds) for write operations. Depending on the hypervisor in use, these times may not always be accurate, sysbench usually warns of this when you run the test. If you run this test on a server that is not running on top of a hypervisor then the response times will be lower and probably more accurate since there isn't a hypervisor involved so keeping track of time is easier.

If the hypervisor is configured to use Write-Back Caching then response times will significantly improve, however it's important to keep in mind that just because the Guest VPS thinks a write is on disk, doesn't mean that is actually the case on the physical host. There is no right way to configure the hypervisor, and enabling write-back caching is fine if the underlying storage is protected from power loss via BBU or other non-volitile flash storage type solutions.

Usually random write performance will be very low if you only use 1 or 2 threads to test performance. Especially if you have a fast CPU. If I run a 4 threaded random write test I get about 2 x performance, at least for the results.

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=4 run

The results below were collected from the same LiquidWeb 1GB SSD VPS from the single threaded test. Notice that the results look much better! IO performance for this vps doubled from almost 10,000 iops to over 20,000 iops.

Operations performed:  0 Read, 5396917 Write, 3445004 Other = 8841921 Total
Read 0b  Written 20.588Gb  Total transferred 20.588Gb  (87.837Mb/sec)
22486.39 Requests/sec executed

Test execution summary:
    total time:                          240.0081s
    total number of events:              5396917
    total time taken by event execution: 56.6653
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.01ms
         max:                                 41.72ms
         approx.  95 percentile:               0.01ms

Generally, you want to keep increasing thread count until your results top out. On most VPS / Cloud Servers this usually happens when the thread count is 2x - 4x server CPU count. This is not always the case though, so I usually run 1,4,8,16,32, and 64 threaded random read and write tests to see how performance scales.

Most VPS instances are on shared physical hosts, so IO will almost always be changing based on what other guests are doing. I suggest running each test 3 or 4 times and then averaging those results to get a general idea on performance. I like to test performance at different times of the day for these averages. 3 tests at noon on a sunday are not going to be the same as 3 tests on monday, tuesday and wednesday at 3PM. The point being, don't trust every benchmark result you see (mine included), test out performance for yourself, using tests that simulate your application / environment.

VPS and Cloud Server Random Read Performance Tests Using Sysbench

As mentioned in the previous section, I like to prepare a set of files to use for random read, or write tests.

For random read tests you need to prepare the test files before you can actually run the random test. I'm using a LiquidWeb 1GB SSD VPS for these examples. I am using a test file size of roughly twice the amount VPS RAM. I do this to avoid the possibility of Linux caching all the data in RAM, at least this way the ratio between file size and RAM is always 2:1 to avoid all reads coming from RAM. I don't want to entirely eliminate caching effects, just reduce them to a more realistic scenario. If you don't think 2:1 is a good ratio then feel free to adjust the file size to whatever you want, this is just an example.

First up, 'run this command to create a total test file size of 2GB.

sysbench --test=fileio --file-total-size=2G --file-num=64 prepare

This is one of the more simple random read tests. The test runs for 240 seconds, uses 1 thread, uses a block size of 4KB, using 64 files that are 32MB in size each. By default Sysbench will use FSYNC after every 100 requests, even if it's a read only test. Syncronous I/O mode is used by default unless you specify async, but that is not supported on all OSs.

You will notice this is almost the exact same command I used for the random write test, the only difference being file-test-mode which is rndrd (random read).

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=1 run

This is what the test result will look like once the test is done. I've removed some of the output to make it easier to display the results as well as to focus on the results that really matter. The results below were collected from LiquidWeb's 1GB SSD VPS I used a single thread for this random read test.

Operations performed:  1013246 Read, 0 Write, 0 Other = 1013246 Total
Read 3.8652Gb  Written 0b  Total transferred 3.8652Gb  (16.492Mb/sec)
 4221.85 Requests/sec executed

Test execution summary:
    total time:                          240.0004s
    total number of events:              1013246
    total time taken by event execution: 238.9431
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.24ms
         max:                                  8.73ms
         approx.  95 percentile:               0.36ms

The most important information to look at from these results are

  • Requests/sec executed: 4221.85

Requests/s executed is more or less IOPS or input / output operations per second. In this case it means that the 1GB LiquidWeb SSD VPS is able to perform 4221.85 (iops) 4KB read operations per second. Some people prefer to view performance in MB/s or even GB/s. Sysbench displays both results (16.492Mb/sec) is roughly equal to 4KB x 4221 = 16,884KB or about 16MB/s. IOPS is much more useful to know, but you must also include the block size used or else the results will be meaningless. A 4KB IOP is not equal to a 16KB IOP. Often times people will use 16KB or 1MB block sizes for random read or write tests which will inflate results because each IOP is transferring more data, so the throughput is higher.

Most of the time you will be dealing with 4KB block sizes so if you are testing random read performance you should really stick with 4KB unless your environment deals with different block sizes.

  • approx. 95 percentile: 0.36ms

IOPS only tells you so much about performance, to get a full picture of IO performance you want to look at the 95% response time as well. This number tells you what 95% of of response times looks like. This is a much more useful metric than "average" or "minimum" response times. Maximum response time is another good metric, but most benchmarking sites and results typically show IOPS and 95% response times. Obviously the goal is to read as much data from RAM as possible, but understanding what non-cached random read performance looks like is pretty important, especially if your application is mainly read only.


Just like the random write test, it's important to run random read tests using different amount of threads. Performance will almost always be higher if you run 4 threaded tests versus single threaded IO tests. Typically random read performance will scale up to around 64 or 128 threads even if you have 1 or 2 CPUs.

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=4 run

With 4 threads, the LiquidWeb 1GB SSD VPS gets about 17,000 IOPS for random read performance. With 95% of the requests completing in under 0.36ms

Operations performed:  4085976 Read, 0 Write, 0 Other = 4085976 Total
Read 15.587Gb  Written 0b  Total transferred 15.587Gb  (66.503Mb/sec)
17024.87 Requests/sec executed

Test execution summary:
    total time:                          240.0004s
    total number of events:              4085976
    total time taken by event execution: 956.7898
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.23ms
         max:                                 38.60ms
         approx.  95 percentile:               0.36ms

Let's get to the point and run a 16 threaded random read test. Keep in mind the server I am running this on has 2 vCPUs and 50GB of SSD storage

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=16 run

This 1GB VPS is almost at 50,000 IOPS for random reads. Not too shabby!

Operations performed:  11679232 Read, 0 Write, 0 Other = 11679232 Total
Read 44.553Gb  Written 0b  Total transferred 44.553Gb  (190.09Mb/sec)
48662.93 Requests/sec executed

Test execution summary:
    total time:                          240.0027s
    total number of events:              11679232
    total time taken by event execution: 3829.1727
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.33ms
         max:                                 51.21ms
         approx.  95 percentile:               0.68ms

Since performance continues to scale I'm going to run a 32 threaded random read test to see what kind of results I get

sysbench --test=fileio --file-total-size=2G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --file-num=64 --num-threads=32 run

LiquidWeb's 1GB SSD VPS performed pretty well for the 32 threaded random read test, reaching almost 64,000 IOPS for random reads.

Operations performed:  15348543 Read, 0 Write, 0 Other = 15348543 Total
Read 58.55Gb  Written 0b  Total transferred 58.55Gb  (249.81Mb/sec)
63951.43 Requests/sec executed

Test execution summary:
    total time:                          240.0031s
    total number of events:              15348543
    total time taken by event execution: 7663.7240
    per-request statistics:
         min:                                  0.00ms
         avg:                                  0.50ms
         max:                                103.57ms
         approx.  95 percentile:               1.27ms

Threads fairness:
    events (avg/stddev):           479641.9688/3418.13
    execution time (avg/stddev):   239.4914/0.02

I could continue to run more tests, but I think you get the idea. Make sure you test IO performance at various thread levels, don't just assume 1 thread will be good enough, many SSD VPS will perform, or at least appear to perform similarly when running light IO tests, but to get an idea of VPS IO performance under heavy IO you need to run at least 8 or 16 threaded tests to get an idea.

Anyway, LiquidWeb's 1GB SSD VPS appear to perform very well.

Intel E5-2690v2 KVM Sysbench CPU Pinning Results

  • Testing using a single VM located on a CentOS 6 box. Running KVM, allocated all 40 vCPUs to the guest instance.

Running Sysbench CPU with 40 threads

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=40 run
  • CPU Affinity all Total Time Taken: 0.9807s

By default each vCPU's CPU affinity will be set to each Host CPU. You can change force this by running the command below

for each in {0..39}; do virsh vcpupin $instance_ID $each 0-39 ; done
  • Each vCPU Pinned to Corresponding Host CPU Total Time Taken: 0.9218s

To optimize performance, I pinned each vCPU to the corresponding host CPU. So vCPU 0 affinity is set to Host CPU 0, etc, etc

for each in {0..39}; do virsh vcpupin $instance_ID $each $each ; done

Super Lazy and Dirty Benchmark Script for Cloud VPS Servers

Assuming you already have the test files and database prepared, and assuming you have installed fio and sysbench and geekbench, this script maybe will work. It will not work well. It's not here to be used by you, it's mainly for me and I like wikis so I store stuff here whenever I can. Yea, I know that Github is a better place for this but you're more than welcome to take this and put it on Github yourself and make it better.

Use caution when running this! (unless you know what the hell you're doing)

#!/bin/bash

screen -S lololololololbenchmarkingvimportant

fio --time_based --name=benchmark --size=8G --runtime=300 --filename=rand --ioengine=libaio --randrepeat=0 --iodepth=32 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=4 --rw=randread --blocksize=4k --group_reporting

sleep 30

rm -f /root/rand

sleep 30

fio --time_based --name=benchmark --size=8G --runtime=300 --filename=rand --ioengine=libaio --randrepeat=0 --iodepth=32 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=4 --rw=randread --blocksize=4k --group_reporting

rm -f /root/rand

sleep 30

for each in `1 2 4 8` do; sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$each run; sleep 10 ; done

sleep 5

/root/dist/Geekbench-3.3.2-Linux/geekbench_x86_64

sleep 5

mysql -u root -ppassword -e "CREATE DATABASE sysbench;"

mysql -u root -ppassword -e "CREATE USER 'sysbench'@'localhost' IDENTIFIED BY 'password';"

mysql -u root -ppassword -e "GRANT ALL PRIVILEGES ON *.* TO 'sysbench'@'localhost' IDENTIFIED  BY 'password';"

sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password prepare

sleep 30

sysbench --test=fileio --file-total-size=32G  prepare

sleep 30

for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=32G --file-test-mode=rndwr --max-time=240 --max-requests=0 --file-block-size=4K --num-threads=$each --file-extra-flags=direct run; sleep 10; done; for each in 1 4 8 16 32 64; do sysbench --test=fileio --file-total-size=32G --file-test-mode=rndrd --max-time=240 --max-requests=0 --file-block-size=4K --num-threads=$each --file-extra-flags=direct run; sleep 10; done; for each in 1 4 8 16 32; do sysbench --test=oltp --db-driver=mysql --oltp-table-size=40000000 --mysql-db=sysbench --mysql-user=sysbench --mysql-password=password --max-time=240 --max-requests=0 --num-threads=$each run; sleep 30; done