'\" t .\" Title: SYSBENCH .\" Author: Alexey Kopytov .\" Generator: DocBook XSL Stylesheets v1.78.1 .\" Date: 02/12/2014 .\" Manual: sysbench User Manual .\" Source: sysbench .\" Language: English .\" .TH "SYSBENCH" "1" "02/12/2014" "sysbench" "sysbench User Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" sysbench \- A modular, cross\-platform and multi\-threaded benchmark tool\&. .SH "SYNOPSIS" .HP \w'\fBsysbench\fR\ 'u \fBsysbench\fR \fB[common\-options]\fR \fB\-\-test=\fR\fBname\fR \fB[test\-options]\fR \fBcommand\fR .HP \w'\fBsysbench\fR\ 'u \fBsysbench\fR [{\fB\-h\fR\ |\ \fB\-\-help\fR} | {\fB\-v\fR\ |\ \fB\-\-version\fR}] .SH "DESCRIPTION" .PP 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\&. .PP 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\&. .PP Current features allow to test the following system parameters: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} file I/O performance .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} scheduler performance .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} memory allocation and transfer speed .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} POSIX threads implementation performance .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} database server performance .RE .PP 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\&. .PP 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\&. .SH "OPTIONS" .PP \fB\-\-num\-threads\fR .RS 4 The total number of worker threads to create (defaut: 1) .RE .PP \fB\-\-max\-requests\fR .RS 4 Limit for total number of requests\&. 0 means unlimited (defaut: 10000) .RE .PP \fB\-\-max\-time\fR .RS 4 Limit for total execution time in seconds\&. 0 (defaut: 0) .RE .PP \fB\-\-thread\-stack\-size\fR .RS 4 Size of stack for each thread (defaut: 32K) .RE .PP \fB\-\-init\-rnd\fR .RS 4 Specifies if random numbers generator should be initialized from timer before the test start (defaut: off) .RE .PP \fB\-\-test\fR .RS 4 Name of the test mode to run \fIRequired\fR .RE .PP \fB\-\-debug\fR .RS 4 Print more debug info (default: off) .RE .PP \fB\-\-validate\fR .RS 4 Perform validation of test results where possible (default: off) .RE .PP \fB\-\-help\fR .RS 4 Print help on general syntax or on a test mode specified with \-\-test, and exit .RE .PP \fB\-\-version\fR .RS 4 Show version of program\&. .RE .PP \fB\-\-percentile\fR .RS 4 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)\&. .sp This option allows to specify a percentile rank of query execution times to count (default: 95) .RE .PP \fB\-\-batch\fR .RS 4 Dump current results periodically (default: off \- see also the section called \(lqBatch mode\(rq) .RE .PP \fB\-\-batch\-delay\fR .RS 4 Delay between batch dumps in secods (default: 300 \- see also the section called \(lqBatch mode\(rq) .RE .PP Note that numerical values for all \fIsize\fR options (like \fB\-\-thread\-stack\-size\fR 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)\&. .SS "Batch mode" .PP 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 \fB\-\-batch\fR option\&. You may specify the delay in seconds between the consequent dumps with the \fB\-\-batch\-delay\fR option\&. .PP Example: .sp .if n \{\ .RS 4 .\} .nf sysbench \-\-batch \-\-batch\-delay=5 \-\-test=threads run .fi .if n \{\ .RE .\} .PP 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\&. .SS "Test modes" .PP This section gives a detailed description for each test mode available in SysBench\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBcpu\fR .RS 4 .PP The \fBcpu\fR 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 \fB\-\-cpu\-max\-primes\fR option\&. All calculations are performed using 64\-bit integers\&. .PP 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\&. .PP Example: .sp .if n \{\ .RS 4 .\} .nf sysbench \-\-test=cpu \-\-cpu\-max\-prime=20000 run .fi .if n \{\ .RE .\} .sp .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBthreads\fR .RS 4 .PP 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\&. .PP 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\&. .PP The following options are available in this test mode: .PP \fB\-\-thread\-yields\fR .RS 4 Number of \fIlock/yield/unlock\fR loops to execute per each request (default: 1000) .RE .PP \fB\-\-thread\-locks\fR .RS 4 Number of mutexes to create (default: 8) .RE .PP Example: .sp .if n \{\ .RS 4 .\} .nf sysbench \-\-num\-threads=64 \-\-test=threads \-\-thread\-yields=100 \-\-thread\-locks=2 run .fi .if n \{\ .RE .\} .sp .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBmutex\fR .RS 4 .PP 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\&. .PP The following options are available in this test mode: .PP \fB\-\-mutex\-num\fR .RS 4 Number of mutexes\&. The actual mutex to lock is chosen randomly before each lock (default: 4096) .RE .PP \fB\-\-memory\-scope\fR .RS 4 Possible values: \fBglobal\fR, \fBlocal\fR\&. Specifies whether each thread will use a globally allocated memory block, or a local one\&. (default: global) .RE .PP \fB\-\-memory\-total\-size\fR .RS 4 Total size of data to transfer (default: 100G) .RE .PP \fB\-\-memory\-oper\fR .RS 4 Type of memory operations\&. Possible values: \fBread\fR, \fBwrite\fR .RE .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBfileio\fR .RS 4 .PP This test mode can be used to produce various kinds of file I/O workloads\&. At the \fBprepare\fR stage SysBench creates a specified number of files with a specified total size, then at the \fBrun\fR stage, each thread performs specified I/O operations on this set of files\&. .PP When the global \fB\-\-validate\fR option is used with the \fBfileio\fR 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\&. .PP The following I/O operations are supported: .PP \fBseqwr\fR .RS 4 sequential write .RE .PP \fBseqrewr\fR .RS 4 sequential rewrite .RE .PP \fBseqrd\fR .RS 4 sequential read .RE .PP \fBrndrd\fR .RS 4 random read .RE .PP \fBrndwr\fR .RS 4 random write .RE .PP \fBrndrw\fR .RS 4 combined random read/write .RE .PP Also, the following file access modes can be specified, if the underlying platform supports them: .PP Asynchronous I/O mode .RS 4 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\&. .RE .PP Slow \fBmmap()\fR mode .RS 4 In this mode SysBench will use \fBmmap\fR\*(Aqed I/O\&. However, a separate \fBmmap\fR will be used for each I/O request due to the limitation of 32\-bit architectures (we cannot \fBmmap()\fR the whole file, as its size migth possibly exceed the maximum of 2 GB of the process address space)\&. .RE .PP Fast \fBmmap()\fR mode .RS 4 On 64\-bit architectures it is possible to \fBmmap()\fR the whole file into the process address space, avoiding the limitation of 2 GB on 32\-bit platforms\&. .RE .PP Using \fBfdatasync()\fR instead of \fBfsync()\fR .RS 4 Flush only data buffers, but not the metadata\&. .RE .PP Additional flags to \fBopen(2)\fR .RS 4 SysBench can use additional flags to \fBopen(2)\fR, such as \fBO_SYNC\fR, \fBO_DSYNC\fR and \fBO_DIRECT\fR\&. .RE .PP Below is a list of test\-specific option for the \fBfileio\fR mode: .PP \fB\-\-file\-num\fR .RS 4 Number of files to create (default: 128) .RE .PP \fB\-\-file\-block\-size\fR .RS 4 Block size to use in all I/O operations (default: 16K) .RE .PP \fB\-\-file\-total\-size\fR .RS 4 Total size of files (default: 2G) .RE .PP \fB\-\-file\-test\-mode\fR .RS 4 Type of workload to produce\&. Possible values: \fBseqwr\fR, \fBseqrewr\fR, \fBseqrd\fR, \fBrndrd\fR, \fBrndwr\fR, \fBrndwr\fR (see above) \fIrequired\fR .RE .PP \fB\-\-file\-io\-mode\fR .RS 4 I/O mode\&. Possible values: \fBsync\fR, \fBasync\fR, \fBfastmmap\fR, \fBslowmmap\fR (only if supported by the platform, see above)\&. (default: sync) .RE .PP \fB\-\-file\-async\-backlog\fR .RS 4 Number of asynchronous operations to queue per thread (only for \fB\-\-file\-io\-mode=async\fR, see above) (default: 128) .RE .PP \fB\-\-file\-extra\-flags\fR .RS 4 Additional flags to use with \fBopen\fR(2) .RE .PP \fB\-\-file\-fsync\-freq\fR .RS 4 Do \fBfsync()\fR after this number of requests (default: 0 \- don\*(Aqt use \fBfsync()\fR) .RE .PP \fB\-\-file\-fsync\-all\fR .RS 4 Do \fBfsync()\fR after each write operationi (default: no) .RE .PP \fB\-\-file\-fsync\-end\fR .RS 4 Do \fBfsync()\fR at the end of the test (default: yes) .RE .PP \fB\-\-file\-fsync\-mode\fR .RS 4 Which method to use for synchronization\&. Possible values: \fBfsync\fR, \fBfdatasync\fR (default: fsync) .RE .PP \fB\-\-file\-merged\-requests\fR .RS 4 Merge at most this number of I/O requests if possible (default: 0 \- don\*(Aqt merge) .RE .PP \fB\-\-file\-rw\-ratio\fR .RS 4 reads/writes ration for combined random read/write test (default: 1\&.5) .RE .PP Usage example: .sp .if n \{\ .RS 4 .\} .nf $ 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 .fi .if n \{\ .RE .\} .sp 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\&. .RE .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br .ps +1 \fBoltp\fR .RS 4 .PP This test mode was written to benchmark a real database performance\&. At the \fBprepare\fR stage the following table is created in the specified database (\fBsbtest\fR by default): .sp .if n \{\ .RS 4 .\} .nf CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL auto_increment, `k` int(10) unsigned NOT NULL default \*(Aq0\*(Aq, `c` char(120) NOT NULL default \*(Aq\*(Aq, `pad` char(60) NOT NULL default \*(Aq\*(Aq, PRIMARY KEY (`id`), KEY `k` (`k`); .fi .if n \{\ .RE .\} .sp Then this table is filled with a specified number of rows\&. .PP The following execution modes are available at the \fBrun\fR stage: .PP Simple .RS 4 In this mode each thread runs simple queries of the following form: .sp .if n \{\ .RS 4 .\} .nf SELECT c FROM sbtest WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp where \fIN\fR takes a random value in range 1\&.\&.\fI\fR .RE .PP Advanced transactional .RS 4 Each thread performs transactions on the test table\&. If the test table and database support transactions (e\&.g\&. InnoDB engine in MySQL), then \fBBEGIN\fR/\fBCOMMIT\fR statements will be used to start/stop a transaction\&. Otherwise, SysBench will use \fBLOCK TABLES\fR/\fBUNLOCK TABLES \fR 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\&. .sp Depending on the command line options, each transaction may contain the following statements: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Point queries: .sp .if n \{\ .RS 4 .\} .nf SELECT c FROM sbtest WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Range queries: .sp .if n \{\ .RS 4 .\} .nf SELECT c FROM sbtest WHERE id BETWEEN \fIN\fR AND \fIM\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Range SUM() queries: .sp .if n \{\ .RS 4 .\} .nf SELECT SUM(K) FROM sbtest WHERE id BETWEEN \fIN\fR and \fIM\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Range ORDER BY queries: .sp .if n \{\ .RS 4 .\} .nf SELECT c FROM sbtest WHERE id between \fIN\fR and \fIM\fR ORDER BY c .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Range DISTINCT queries: .sp .if n \{\ .RS 4 .\} .nf SELECT DISTINCT c FROM sbtest WHERE id BETWEEN \fIN\fR and \fIM\fR ORDER BY c .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} UPDATEs on index column: .sp .if n \{\ .RS 4 .\} .nf UPDATE sbtest SET k=k+1 WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} UPDATEs on non\-index column: .sp .if n \{\ .RS 4 .\} .nf UPDATE sbtest SET c=\fIN\fR WHERE id=\fIM\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} DELETE queries: .sp .if n \{\ .RS 4 .\} .nf DELETE FROM sbtest WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} INSERT queries: .sp .if n \{\ .RS 4 .\} .nf INSERT INTO sbtest VALUES (\fI\&.\&.\&.\fR) .fi .if n \{\ .RE .\} .sp .RE .sp .RE .PP Non\-transactional .RS 4 This mode is similar to \fBSimple\fR, but you can also choose the query to run\&. Note that unlike the \fBAdvanced transactional\fR mode, this one does not preserve the test table between requests, so you should recreate it with the appropriate \fBcleanup\fR/\fBprepare\fR commands between consecutive benchmarks\&. .sp Below is a list of possible queries: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Point queries: .sp .if n \{\ .RS 4 .\} .nf SELECT pad FROM sbtest WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} UPDATEs on index column: .sp .if n \{\ .RS 4 .\} .nf UPDATE sbtest SET k=k+1 WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} UPDATEs on non\-index column: .sp .if n \{\ .RS 4 .\} .nf UPDATE sbtest SET c=\fIN\fR WHERE id=\fIM\fR .fi .if n \{\ .RE .\} .sp .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} DELETE queries: .sp .if n \{\ .RS 4 .\} .nf DELETE FROM sbtest WHERE id=\fIN\fR .fi .if n \{\ .RE .\} .sp The generated row IDs are unique over each test run, so no row is deleted twice\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} INSERT queries: .sp .if n \{\ .RS 4 .\} .nf INSERT INTO sbtest (k, c, pad) VALUES(\fIN\fR, \fIM\fR, \fIS\fR) .fi .if n \{\ .RE .\} .sp .RE .sp .RE .PP .PP \fB\-\-oltp\-test\-mode\fR .RS 4 Execution mode (see above)\&. Possible values: \fBsimpe\fR (simple), \fBcomplex\fR (advanced transactional) and \fBnontrx\fR (non\-transactional) (default: complex) .RE .PP \fB\-\-oltp\-read\-only\fR .RS 4 Read\-only mode\&. No \fBUPDATE\fR, \fBDELETE\fR or \fBINSERT\fR queries will be performed\&. (default: off) .RE .PP \fB\-\-oltp\-range\-size\fR .RS 4 Range size for range queries (default: 100) .RE .PP \fB\-\-oltp\-point\-selects\fR .RS 4 Number of point select queries in a single transaction (default: 10) .RE .PP \fB\-\-oltp\-simple\-ranges\fR .RS 4 Number of simple range queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-sum\-ranges\fR .RS 4 Number of SUM range queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-order\-ranges\fR .RS 4 Number of ORDER range queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-distinct\-ranges\fR .RS 4 Number of DISTINCT range queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-index\-updates\fR .RS 4 Number of index UPDATE queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-non\-index\-updates\fR .RS 4 Number of non\-index UPDATE queries in a single transaction (default: 1) .RE .PP \fB\-\-oltp\-nontrx\-mode\fR .RS 4 Type of queries for non\-transactional execution mode (see above)\&. Possible values: \fBselect\fR, \fBupdate_key\fR, \fBupdate_nokey\fR, \fBinsert\fR, \fBdelete\fR\&. (default: select) .RE .PP \fB\-\-oltp\-connect\-delay\fR .RS 4 Time in microseconds to sleep after each connection to database (default: 10000) .RE .PP \fB\-\-oltp\-user\-delay\-min\fR .RS 4 Minimum time in microseconds to sleep after each request (default: 0) .RE .PP \fB\-\-oltp\-user\-delay\-max\fR .RS 4 Maximum time in microseconds to sleep after each request (default: 0) .RE .PP \fB\-\-oltp\-table\-name\fR .RS 4 Name of the test table (default: sbtest) .RE .PP \fB\-\-oltp\-table\-size\fR .RS 4 Number of rows in the test table (default: 10000) .RE .PP \fB\-\-oltp\-dist\-type\fR .RS 4 Distribution of random numbers\&. Possible values: \fBuniform\fR (uniform distribution), \fBgauss\fR (gaussian distribution) and \fBspecial\fR\&. (default: special) .sp With special distribution a specified percent of numbers is generated in a specified percent of cases (see options below)\&. .RE .PP \fB\-\-oltp\-dist\-pct\fR .RS 4 Percentage of values to be treated as \*(Aqspecial\*(Aq (for special distribution) (default: 1) .RE .PP \fB\-\-oltp\-dist\-res\fR .RS 4 Percentage of cases when \*(Aqspecial\*(Aq values are generated (for special distribution) (default: 75) .RE .PP \fB\-\-db\-ps\-mode\fR .RS 4 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: \fBdisable\fR, \fBauto\fR\&. (default: auto) .RE .PP Also, each database driver may provide its own options\&. Currently only MySQL driver is available\&. Below is a list of MySQL\-specific options: .PP \fB\-\-mysql\-host\fR .RS 4 MySQL server host\&. (default: localhost) .sp 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\&. .RE .PP \fB\-\-mysql\-port\fR .RS 4 MySQL server port (in case TCP/IP connection should be used) (default: 3306) .RE .PP \fB\-\-mysql\-socket\fR .RS 4 Unix socket file to communicate with the MySQL server .RE .PP \fB\-\-mysql\-user\fR .RS 4 MySQL user (default: user) .RE .PP \fB\-\-mysql\-password\fR .RS 4 MySQL password .RE .PP \fB\-\-mysql\-db\fR .RS 4 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) .RE .PP \fB\-\-mysql\-table\-engine\fR .RS 4 Type of the test table\&. Possible values: \fBmyisam\fR, \fBinnodb\fR, \fBheap\fR, \fBndbcluster\fR, \fBbdb\fR, \fBmaria\fR, \fBfalcon\fR, \fBpbxt\fR (default: innodb) .RE .PP \fB\-\-mysql\-ssl\fR .RS 4 Use SSL connections\&. (default: no) .RE .PP \fB\-\-myisam\-max\-rows\fR .RS 4 MAX_ROWS option for MyISAM tables (required for big tables) (default: 1000000) .RE .PP \fB\-\-mysql\-create\-options\fR .RS 4 Additional options passed to CREATE TABLE\&. .RE .PP Example usage: .sp .if n \{\ .RS 4 .\} .nf $ 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 .fi .if n \{\ .RE .\} .sp The first command will create a MyISAM table \*(Aqsbtest\*(Aq in a database \*(Aqsbtest\*(Aq on a MySQL server using \fB/tmp/mysql\&.sock\fR 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\&. .RE .SH "AUTHOR" .PP \fBAlexey Kopytov\fR <\&kaamos@users\&.sourceforge\&.net\&> .RS 4 Author. .RE .SH "COPYRIGHT" .br Copyright \(co 2004-2008 MySQL AB .br .PP This manual page was rewritten for the Debian system (and may be used by others) from the manual\&.xml of the original package\&. .PP 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\&. .PP On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common\-licenses/GPL\&. .sp