NAME
sysbench - A modular, cross-platform and multi-threaded benchmark tool.
SYNOPSIS
sysbench [common-options] --test=name [test-options] command
sysbench [{-h | --help} | {-v | --version}]
DESCRIPTION
SysBench is a modular, cross-platform and multi-threaded benchmark tool
for evaluating OS parameters that are important for a system running a
database under intensive load.
The idea of this benchmark suite is to quickly get an impression about
system performance without setting up complex database benchmarks or
even without installing a database at all.
Current features allow to test the following system parameters:
· file I/O performance
· scheduler performance
· memory allocation and transfer speed
· POSIX threads implementation performance
· database server performance
The design is very simple. SysBench runs a specified number of threads
and they all execute requests in parallel. The actual workload produced
by requests depends on the specified test mode. You can limit either
the total number of requests or the total time for the benchmark, or
both.
Available test modes are implemented by compiled-in modules, and
SysBench was designed to make adding new test modes an easy task. Each
test mode may have additional (or workload-specific) options.
OPTIONS
--num-threads
The total number of worker threads to create (defaut: 1)
--max-requests
Limit for total number of requests. 0 means unlimited (defaut:
10000)
--max-time
Limit for total execution time in seconds. 0 (defaut: 0)
--thread-stack-size
Size of stack for each thread (defaut: 32K)
--init-rnd
Specifies if random numbers generator should be initialized from
timer before the test start (defaut: off)
--test
Name of the test mode to run Required
--debug
Print more debug info (default: off)
--validate
Perform validation of test results where possible (default: off)
--help
Print help on general syntax or on a test mode specified with
--test, and exit
--version
Show version of program.
--percentile
SysBench measures execution times for all processed requests to
display statistical information like minimal, average and maximum
execution time. For most benchmarks it is also useful to know a
request execution time value matching some percentile (e.g. 95%
percentile means we should drop 5% of the most long requests and
choose the maximal value from the remaining ones).
This option allows to specify a percentile rank of query execution
times to count (default: 95)
--batch
Dump current results periodically (default: off - see also the
section called “Batch mode”)
--batch-delay
Delay between batch dumps in secods (default: 300 - see also the
section called “Batch mode”)
Note that numerical values for all size options (like
--thread-stack-size in this table) may be specified by appending the
corresponding multiplicative suffix (K for kilobytes, M for megabytes,
G for gigabytes and T for terabytes).
Batch mode
In some cases it is useful to have not only the final benchmarks
statistics, but also periodical dumps of current stats to see how they
change over the test run. For this purpose SysBench has a batch
execution mode which is turned on by the --batch option. You may
specify the delay in seconds between the consequent dumps with the
--batch-delay option.
Example:
sysbench --batch --batch-delay=5 --test=threads run
This will run SysBench in a threads test mode, with the current values
of minimum, average, maximum and percentile for request execution times
printed every 5 seconds.
Test modes
This section gives a detailed description for each test mode available
in SysBench.
cpu
The cpu is one of the most simple benchmarks in SysBench. In this
mode each request consists in calculation of prime numbers up to a
value specified by the --cpu-max-primes option. All calculations
are performed using 64-bit integers.
Each thread executes the requests concurrently until either the
total number of requests or the total execution time exceed the
limits specified with the common command line options.
Example:
sysbench --test=cpu --cpu-max-prime=20000 run
threads
This test mode was written to benchmark scheduler performance, more
specifically the cases when a scheduler has a large number of
threads competing for some set of mutexes.
SysBench creates a specified number of threads and a specified
number of mutexes. Then each thread starts running the requests
consisting of locking the mutex, yielding the CPU, so the thread is
placed in the run queue by the scheduler, then unlocking the mutex
when the thread is rescheduled back to execution. For each request,
the above actions are run several times in a loop, so the more
iterations is performed, the more concurrency is placed on each
mutex.
The following options are available in this test mode:
--thread-yields
Number of lock/yield/unlock loops to execute per each request
(default: 1000)
--thread-locks
Number of mutexes to create (default: 8)
Example:
sysbench --num-threads=64 --test=threads --thread-yields=100 --thread-locks=2 run
mutex
This test mode was written to emulate a situation when all threads
run concurrently most of the time, acquiring the mutex lock only
for a short period of time (incrementing a global variable). So the
purpose of this benchmarks is to examine the performance of mutex
implementation.
The following options are available in this test mode:
--mutex-num
Number of mutexes. The actual mutex to lock is chosen randomly
before each lock (default: 4096)
--memory-scope
Possible values: global, local. Specifies whether each thread
will use a globally allocated memory block, or a local one.
(default: global)
--memory-total-size
Total size of data to transfer (default: 100G)
--memory-oper
Type of memory operations. Possible values: read, write
fileio
This test mode can be used to produce various kinds of file I/O
workloads. At the prepare stage SysBench creates a specified number
of files with a specified total size, then at the run stage, each
thread performs specified I/O operations on this set of files.
When the global --validate option is used with the fileio test
mode, SysBench performs checksums validation on all data read from
the disk. On each write operation the block is filled with random
values, then the checksum is calculated and stored in the block
along with the offset of this block within a file. On each read
operation the block is validated by comparing the stored offset
with the real offset, and the stored checksum with the real
calculated checksum.
The following I/O operations are supported:
seqwr
sequential write
seqrewr
sequential rewrite
seqrd
sequential read
rndrd
random read
rndwr
random write
rndrw
combined random read/write
Also, the following file access modes can be specified, if the
underlying platform supports them:
Asynchronous I/O mode
At the moment only Linux AIO implementation is supported. When
running in asynchronous mode, SysBench queues a specified
number of I/O requests using Linux AIO API, then waits for at
least one of submitted requests to complete. After that a new
series of I/O requests is submitted.
Slow mmap() mode
In this mode SysBench will use mmap'ed I/O. However, a separate
mmap will be used for each I/O request due to the limitation of
32-bit architectures (we cannot mmap() the whole file, as its
size migth possibly exceed the maximum of 2 GB of the process
address space).
Fast mmap() mode
On 64-bit architectures it is possible to mmap() the whole file
into the process address space, avoiding the limitation of 2 GB
on 32-bit platforms.
Using fdatasync() instead of fsync()
Flush only data buffers, but not the metadata.
Additional flags to open(2)
SysBench can use additional flags to open(2), such as O_SYNC,
O_DSYNC and O_DIRECT.
Below is a list of test-specific option for the fileio mode:
--file-num
Number of files to create (default: 128)
--file-block-size
Block size to use in all I/O operations (default: 16K)
--file-total-size
Total size of files (default: 2G)
--file-test-mode
Type of workload to produce. Possible values: seqwr, seqrewr,
seqrd, rndrd, rndwr, rndwr (see above) required
--file-io-mode
I/O mode. Possible values: sync, async, fastmmap, slowmmap
(only if supported by the platform, see above). (default: sync)
--file-async-backlog
Number of asynchronous operations to queue per thread (only for
--file-io-mode=async, see above) (default: 128)
--file-extra-flags
Additional flags to use with open(2)
--file-fsync-freq
Do fsync() after this number of requests (default: 0 - don't
use fsync())
--file-fsync-all
Do fsync() after each write operationi (default: no)
--file-fsync-end
Do fsync() at the end of the test (default: yes)
--file-fsync-mode
Which method to use for synchronization. Possible values:
fsync, fdatasync (default: fsync)
--file-merged-requests
Merge at most this number of I/O requests if possible (default:
0 - don't merge)
--file-rw-ratio
reads/writes ration for combined random read/write test
(default: 1.5)
Usage example:
$ sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw prepare
$ sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw run
$ sysbench --num-threads=16 --test=fileio --file-total-size=3G --file-test-mode=rndrw cleanup
In the above example the first command creates 128 files with the
total size of 3 GB in the current directory, the second command
runs the actual benchmark and displays the results upon completion,
and the third one removes the files used for the test.
oltp
This test mode was written to benchmark a real database
performance. At the prepare stage the following table is created in
the specified database (sbtest by default):
CREATE TABLE ‘sbtest‘ (
‘id‘ int(10) unsigned NOT NULL auto_increment,
‘k‘ int(10) unsigned NOT NULL default '0',
‘c‘ char(120) NOT NULL default '',
‘pad‘ char(60) NOT NULL default '',
PRIMARY KEY (‘id‘),
KEY ‘k‘ (‘k‘);
Then this table is filled with a specified number of rows.
The following execution modes are available at the run stage:
Simple
In this mode each thread runs simple queries of the following
form:
SELECT c FROM sbtest WHERE id=N
where N takes a random value in range 1..<table size>
Advanced transactional
Each thread performs transactions on the test table. If the
test table and database support transactions (e.g. InnoDB
engine in MySQL), then BEGIN/COMMIT statements will be used to
start/stop a transaction. Otherwise, SysBench will use LOCK
TABLES/UNLOCK TABLES statements (e.g. for MyISAM engine in
MySQL). If some rows are deleted in a transaction, the same
rows will be inserted within the same transaction, so this test
mode does not destruct any data in the test table and can be
run multiple times on the same table.
Depending on the command line options, each transaction may
contain the following statements:
· Point queries:
SELECT c FROM sbtest WHERE id=N
· Range queries:
SELECT c FROM sbtest WHERE id BETWEEN N AND M
· Range SUM() queries:
SELECT SUM(K) FROM sbtest WHERE id BETWEEN N and M
· Range ORDER BY queries:
SELECT c FROM sbtest WHERE id between N and M ORDER BY c
· Range DISTINCT queries:
SELECT DISTINCT c FROM sbtest WHERE id BETWEEN N and M ORDER BY c
· UPDATEs on index column:
UPDATE sbtest SET k=k+1 WHERE id=N
· UPDATEs on non-index column:
UPDATE sbtest SET c=N WHERE id=M
· DELETE queries:
DELETE FROM sbtest WHERE id=N
· INSERT queries:
INSERT INTO sbtest VALUES (...)
Non-transactional
This mode is similar to Simple, but you can also choose the
query to run. Note that unlike the Advanced transactional mode,
this one does not preserve the test table between requests, so
you should recreate it with the appropriate cleanup/prepare
commands between consecutive benchmarks.
Below is a list of possible queries:
· Point queries:
SELECT pad FROM sbtest WHERE id=N
· UPDATEs on index column:
UPDATE sbtest SET k=k+1 WHERE id=N
· UPDATEs on non-index column:
UPDATE sbtest SET c=N WHERE id=M
· DELETE queries:
DELETE FROM sbtest WHERE id=N
The generated row IDs are unique over each test run, so no
row is deleted twice.
· INSERT queries:
INSERT INTO sbtest (k, c, pad) VALUES(N, M, S)
--oltp-test-mode
Execution mode (see above). Possible values: simpe (simple),
complex (advanced transactional) and nontrx (non-transactional)
(default: complex)
--oltp-read-only
Read-only mode. No UPDATE, DELETE or INSERT queries will be
performed. (default: off)
--oltp-range-size
Range size for range queries (default: 100)
--oltp-point-selects
Number of point select queries in a single transaction
(default: 10)
--oltp-simple-ranges
Number of simple range queries in a single transaction
(default: 1)
--oltp-sum-ranges
Number of SUM range queries in a single transaction (default:
1)
--oltp-order-ranges
Number of ORDER range queries in a single transaction (default:
1)
--oltp-distinct-ranges
Number of DISTINCT range queries in a single transaction
(default: 1)
--oltp-index-updates
Number of index UPDATE queries in a single transaction
(default: 1)
--oltp-non-index-updates
Number of non-index UPDATE queries in a single transaction
(default: 1)
--oltp-nontrx-mode
Type of queries for non-transactional execution mode (see
above). Possible values: select, update_key, update_nokey,
insert, delete. (default: select)
--oltp-connect-delay
Time in microseconds to sleep after each connection to database
(default: 10000)
--oltp-user-delay-min
Minimum time in microseconds to sleep after each request
(default: 0)
--oltp-user-delay-max
Maximum time in microseconds to sleep after each request
(default: 0)
--oltp-table-name
Name of the test table (default: sbtest)
--oltp-table-size
Number of rows in the test table (default: 10000)
--oltp-dist-type
Distribution of random numbers. Possible values: uniform
(uniform distribution), gauss (gaussian distribution) and
special. (default: special)
With special distribution a specified percent of numbers is
generated in a specified percent of cases (see options below).
--oltp-dist-pct
Percentage of values to be treated as 'special' (for special
distribution) (default: 1)
--oltp-dist-res
Percentage of cases when 'special' values are generated (for
special distribution) (default: 75)
--db-ps-mode
If the database driver supports Prepared Statements API,
SysBench will use server-side prepared statements for all
queries where possible. Otherwise, client-side (or emulated)
prepared statements will be used. This option allows to force
using emulation even when PS API is available. Possible values:
disable, auto. (default: auto)
Also, each database driver may provide its own options. Currently
only MySQL driver is available. Below is a list of MySQL-specific
options:
--mysql-host
MySQL server host. (default: localhost)
Starting from version 0.4.5 you may specify a list of hosts
separated by commas. In this case SysBench will distribute
connections between specified MySQL hosts on a round-robin
basis. Note that all connection ports and passwords must be the
same on all hosts. Also, databases and tables must be prepared
explicitely on each host before executing the benchmark.
--mysql-port
MySQL server port (in case TCP/IP connection should be used)
(default: 3306)
--mysql-socket
Unix socket file to communicate with the MySQL server
--mysql-user
MySQL user (default: user)
--mysql-password
MySQL password
--mysql-db
MySQL database name. Note SysBench will not automatically
create this database. You should create it manually and grant
the appropriate privileges to a user which will be used to
access the test table. (default: sbtest)
--mysql-table-engine
Type of the test table. Possible values: myisam, innodb, heap,
ndbcluster, bdb, maria, falcon, pbxt (default: innodb)
--mysql-ssl
Use SSL connections. (default: no)
--myisam-max-rows
MAX_ROWS option for MyISAM tables (required for big tables)
(default: 1000000)
--mysql-create-options
Additional options passed to CREATE TABLE.
Example usage:
$ sysbench --test=oltp --mysql-table-type=myisam --oltp-table-size=1000000 --mysql-socket=/tmp/mysql.sock prepare
$ sysbench --num-threads=16 --max-requests=100000 --test=oltp --oltp-table-size=1000000 --mysql-socket=/tmp/mysql.sock --oltp-read-only run
The first command will create a MyISAM table 'sbtest' in a database
'sbtest' on a MySQL server using /tmp/mysql.sock socket, then fill
this table with 1M records. The second command will run the actual
benchmark with 16 client threads, limiting the total number of
request by 100,000.
AUTHOR
Alexey Kopytov <kaamos@users.sourceforge.net>
Author.
COPYRIGHT
Copyright © 2004-2008 MySQL AB
This manual page was rewritten for the Debian system (and may be used
by others) from the manual.xml of the original package.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU General Public License, Version 2 or (at
your option) any later version published by the Free Software
Foundation.
On Debian systems, the complete text of the GNU General Public License
can be found in /usr/share/common-licenses/GPL.