SYSBENCH(1) | sysbench User Manual | SYSBENCH(1) |
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:
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--max-requests
--max-time
--thread-stack-size
--init-rnd
--test
--debug
--validate
--help
--version
--percentile
This option allows to specify a percentile rank of query execution times to count (default: 95)
--batch
--batch-delay
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
--thread-locks
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
--memory-scope
--memory-total-size
--memory-oper
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
seqrewr
seqrd
rndrd
rndwr
rndrw
Also, the following file access modes can be specified, if the underlying platform supports them:
Asynchronous I/O mode
Slow mmap() mode
Fast mmap() mode
Using fdatasync() instead of fsync()
Additional flags to open(2)
Below is a list of test-specific option for the fileio mode:
--file-num
--file-block-size
--file-total-size
--file-test-mode
--file-io-mode
--file-async-backlog
--file-extra-flags
--file-fsync-freq
--file-fsync-all
--file-fsync-end
--file-fsync-mode
--file-merged-requests
--file-rw-ratio
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
SELECT c FROM sbtest WHERE id=N
where N takes a random value in range 1..<table size>
Advanced transactional
Depending on the command line options, each transaction may contain the following statements:
SELECT c FROM sbtest WHERE id=N
SELECT c FROM sbtest WHERE id BETWEEN N AND M
SELECT SUM(K) FROM sbtest WHERE id BETWEEN N and M
SELECT c FROM sbtest WHERE id between N and M ORDER BY c
SELECT DISTINCT c FROM sbtest WHERE id BETWEEN N and M ORDER BY c
UPDATE sbtest SET k=k+1 WHERE id=N
UPDATE sbtest SET c=N WHERE id=M
DELETE FROM sbtest WHERE id=N
INSERT INTO sbtest VALUES (...)
Non-transactional
Below is a list of possible queries:
SELECT pad FROM sbtest WHERE id=N
UPDATE sbtest SET k=k+1 WHERE id=N
UPDATE sbtest SET c=N WHERE id=M
DELETE FROM sbtest WHERE id=N
The generated row IDs are unique over each test run, so no row is deleted twice.
INSERT INTO sbtest (k, c, pad) VALUES(N, M, S)
--oltp-test-mode
--oltp-read-only
--oltp-range-size
--oltp-point-selects
--oltp-simple-ranges
--oltp-sum-ranges
--oltp-order-ranges
--oltp-distinct-ranges
--oltp-index-updates
--oltp-non-index-updates
--oltp-nontrx-mode
--oltp-connect-delay
--oltp-user-delay-min
--oltp-user-delay-max
--oltp-table-name
--oltp-table-size
--oltp-dist-type
With special distribution a specified percent of numbers is generated in a specified percent of cases (see options below).
--oltp-dist-pct
--oltp-dist-res
--db-ps-mode
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
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-socket
--mysql-user
--mysql-password
--mysql-db
--mysql-table-engine
--mysql-ssl
--myisam-max-rows
--mysql-create-options
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>COPYRIGHT¶
Copyright © 2004-2008 MySQL ABThis 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.
11/03/2016 | sysbench |