Files
sysbench/doc/manual.html
Alexey Kopytov c5e2681c36 Added --mysql-ssl option
Added --oltp-reconnect option
Workaround for overoptimized gettimeofday() implementations
Fixed issues with random numbers generator on Solaris
Version 0.4.7
2006-05-24 13:58:09 +00:00

935 lines
52 KiB
HTML

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<title>SysBench manual</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.67.2" />
</head>
<body>
<div class="book" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a id="sysbench-guide"></a>SysBench manual</h1>
</div>
<div>
<div class="authorgroup">
<div class="author">
<h3 class="author"><span class="firstname">Alexey</span> <span class="surname">Kopytov</span></h3>
<div class="affiliation">
<div class="address">
<p>
<code class="email">&lt;<a href="mailto:kaamos@users.sourceforge.net">kaamos@users.sourceforge.net</a>&gt;</code>
</p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="copyright">Copyright © 2004-2006 MySQL AB</p>
</div>
</div>
<hr />
</div>
<div class="toc">
<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>
<span class="chapter">
<a href="#introduction">1. Introduction</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="#features">1. Features of SysBench</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#design">2. Design</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#links">3. Links</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#install">4. Installation</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="#usage">2. Usage</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="#general_syntax">1. General syntax</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#common_options">2. Common command line options</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#batch_mode">3. Batch mode</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#test_modes">4. Test modes</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="#cpu_mode">4.1. <code class="option">cpu</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#threads_mode">4.2. <code class="option">threads</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#mutex_mode">4.3. <code class="option">mutex</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#memory_mode">4.4. <code class="option">memory</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#fileio_mode">4.5. <code class="option">fileio</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#database_mode">4.6. <code class="option">oltp</code></a>
</span>
</dt>
</dl>
</dd>
</dl>
</dd>
</dl>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="introduction"></a>Chapter 1. Introduction</h2>
</div>
</div>
</div>
<div class="toc">
<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>
<span class="section">
<a href="#features">1. Features of SysBench</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#design">2. Design</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#links">3. Links</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#install">4. Installation</a>
</span>
</dt>
</dl>
</div>
<p>
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.
</p>
<p>
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.
</p>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="features"></a>1. Features of SysBench</h2>
</div>
</div>
</div>
<p>
Current features allow to test the following system parameters:
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>file I/O performance</p>
</li>
<li>
<p>scheduler performance</p>
</li>
<li>
<p>memory allocation and transfer speed</p>
</li>
<li>
<p>POSIX threads implementation performance</p>
</li>
<li>
<p>database server performance</p>
</li>
</ul>
</div>
<p>
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="design"></a>2. Design</h2>
</div>
</div>
</div>
<p>
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.
</p>
<p>
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.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="links"></a>3. Links</h2>
</div>
</div>
</div>
<div class="variablelist">
<dl>
<dt>
<span class="term">Home page</span>
</dt>
<dd>
<p>
<a href="http://sysbench.sf.net/">http://sysbench.sf.net/</a>.
</p>
</dd>
<dt>
<span class="term">Download</span>
</dt>
<dd>
<p>
<a href="http://sf.net/projects/sysbench/">http://sf.net/projects/sysbench/</a>.
</p>
</dd>
<dt>
<span class="term">Mailing lists</span>
</dt>
<dd>
<p>
<a href="http://sourceforge.net/mail/?group_id=102348">sysbench-general</a>
</p>
</dd>
<dt>
<span class="term">Web forums</span>
</dt>
<dd>
<p>
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<a href="http://sourceforge.net/forum/forum.php?forum_id=353125">Developers</a>
</li>
<li>
<a href="http://sourceforge.net/forum/forum.php?forum_id=353124">Help</a>
</li>
<li>
<a href="http://sourceforge.net/forum/forum.php?forum_id=353123">Open discussion</a>
</li>
</ul>
</div>
<p>
</p>
</dd>
<dt>
<span class="term">Bug tracking system</span>
</dt>
<dd>
<p>
</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<a href="http://sourceforge.net/tracker/?atid=631676&amp;group_id=102348&amp;func=browse">
Bug reports
</a>
</li>
<li>
<a href="http://sourceforge.net/tracker/?atid=631679&amp;group_id=102348&amp;func=browse">
Feature requests
</a>
</li>
</ul>
</div>
<p>
</p>
</dd>
</dl>
</div>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="install"></a>4. Installation</h2>
</div>
</div>
</div>
<p>
The following standart procedure will be sufficient to build SysBench in most cases:
</p>
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%">
<tr>
<td>
<pre class="synopsis">
<span xmlns="http://www.w3.org/1999/xhtml"><strong class="command">./configure</strong></span>
<span xmlns="http://www.w3.org/1999/xhtml"><strong class="command">make</strong></span>
<span xmlns="http://www.w3.org/1999/xhtml"><strong class="command">make install</strong></span>
</pre>
</td>
</tr>
</table>
<p>
The above procedure will try to compile SysBench with MySQL support by default. If you have MySQL headers and libraries
in non-standard locations (and no <span><strong class="command">mysql_config</strong></span> can be found in the <code class="constant">PATH</code>
environmental variable), then you can specify them explicitly with <code class="option">--with-mysql-includes</code> and
<code class="option">--with-mysql-libs</code> options to <span><strong class="command">./configure</strong></span>.
</p>
<p>
To compile SysBench without MySQL support, use <code class="option">--without-mysql</code>. In this case all database-related
test modes will be unavailable.
</p>
<p>
If you are running on a 64-bit platform, make sure to build a 64-bit binary by passing the proper target platform and compiler options to <span><strong class="command">configure</strong></span> script. You can also consult the INSTALL file for generic installation instructions.
</p>
</div>
</div>
<div class="chapter" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a id="usage"></a>Chapter 2. Usage</h2>
</div>
</div>
</div>
<div class="toc">
<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>
<span class="section">
<a href="#general_syntax">1. General syntax</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#common_options">2. Common command line options</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#batch_mode">3. Batch mode</a>
</span>
</dt>
<dt>
<span class="section">
<a href="#test_modes">4. Test modes</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="#cpu_mode">4.1. <code class="option">cpu</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#threads_mode">4.2. <code class="option">threads</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#mutex_mode">4.3. <code class="option">mutex</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#memory_mode">4.4. <code class="option">memory</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#fileio_mode">4.5. <code class="option">fileio</code></a>
</span>
</dt>
<dt>
<span class="section">
<a href="#database_mode">4.6. <code class="option">oltp</code></a>
</span>
</dt>
</dl>
</dd>
</dl>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="general_syntax"></a>1. General syntax</h2>
</div>
</div>
</div>
<p>
The general syntax for SysBench is as follows:
</p>
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%">
<tr>
<td>
<pre class="screen">
sysbench <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>[common-options]</em></span> --test=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>name</em></span> <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>[test-options]</em></span> <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>command</em></span>
</pre>
</td>
</tr>
</table>
<p>
See <a href="#common_options" title="2. Common command line options">Section 2, &#8220;Common command line options&#8221;</a> for a description of common options and documentation for particular test mode for a list
of test-specific options.
</p>
<p>
Below is a brief description of available commands and their purpose:
</p>
<div class="variablelist">
<dl>
<dt>
<span class="term">
<span>
<strong class="command">prepare</strong>
</span>
</span>
</dt>
<dd>Performs preparative actions for those tests which need them, e.g. creating the necessary
files on disk for the <code class="option">fileio</code> test, or filling the test database for the
<code class="option">oltp</code> test.
</dd>
<dt>
<span class="term">
<span>
<strong class="command">run</strong>
</span>
</span>
</dt>
<dd>Runs the actual test specified with the <code class="option">--test=<span class="emphasis"><em>name</em></span></code> option.
</dd>
<dt>
<span class="term">
<span>
<strong class="command">cleanup</strong>
</span>
</span>
</dt>
<dd>Removes temporary data after the test run in those tests which create one.
</dd>
<dt>
<span class="term">
<span>
<strong class="command">help</strong>
</span>
</span>
</dt>
<dd>Displays usage information for a test specified with the
<code class="option">--test=<span class="emphasis"><em>name</em></span></code> option.
</dd>
</dl>
</div>
<p>
</p>
<p>
Also you can use <span><strong class="command">sysbench help</strong></span> to display the brief usage summary and the list of available test modes.
</p>
</div>
<div class="section" lang="en" xml:lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="common_options"></a>2. Common command line options</h2>
</div>
</div>
</div>
<p>
The table below lists the supported common options, their descriptions and default values:
</p>
<div class="informaltable">
<table border="1">
<colgroup>
<col />
<col />
<col />
</colgroup>
<tbody>
<tr>
<td>
<span class="emphasis">
<em>Option</em>
</span>
</td>
<td>
<span class="emphasis">
<em>Description</em>
</span>
</td>
<td>
<span class="emphasis">
<em>Default value</em>
</span>
</td>
</tr>
<tr>
<td>
<code class="option">--num-threads</code>
</td>
<td>The total number of worker threads to create</td>
<td>1</td>
</tr>
<tr>
<td>
<code class="option">--max-requests</code>
</td>
<td>Limit for total number of requests. 0 means unlimited</td>
<td>10000</td>
</tr>
<tr>
<td>
<code class="option">--max-time</code>
</td>
<td>Limit for total execution time in seconds. 0 (default) means unlimited</td>
<td>0</td>
</tr>
<tr>
<td>
<code class="option">--thread-stack-size</code>
</td>
<td>Size of stack for each thread</td>
<td>32K</td>
</tr>
<tr>
<td>
<code class="option">--init-rnd</code>
</td>
<td>Specifies if random numbers generator should be initialized from timer before the test start</td>
<td>off</td>
</tr>
<tr>
<td>
<code class="option">--test</code>
</td>
<td>Name of the test mode to run</td>
<td>
<span class="emphasis">
<em>Required</em>
</span>
</td>
</tr>
<tr>
<td>
<code class="option">--debug</code>
</td>
<td>Print more debug info</td>
<td>off</td>
</tr>
<tr>
<td>
<code class="option">--validate</code>
</td>
<td>Perform
validation of test results where possible </td>
<td>off</td>
</tr>
<tr>
<td>
<code class="option">--help</code>
</td>
<td>Print help on general syntax or on a test mode specified with --test, and exit</td>
<td>off</td>
</tr>
<tr>
<td>
<code class="option">--verbosity</code>
</td>
<td>Verbosity level (0 - only critical messages, 5 - debug)</td>
<td>4</td>
</tr>
<tr>
<td>
<code class="option">--percentile</code>
</td>
<td>
<p>
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).
</p>
<p>
This option allows to specify a percentile rank of query
execution times to count
</p>
</td>
<td>95</td>
</tr>
<tr>
<td>
<code class="option">--batch</code>
</td>
<td>Dump current results periodically (see <a href="#batch_mode" title="3. Batch mode">Section 3, &#8220;Batch mode&#8221;</a>)</td>
<td>off</td>
</tr>
<tr>
<td>
<code class="option">--batch-delay</code>
</td>
<td>Delay between batch dumps in secods (see <a href="#batch_mode" title="3. Batch mode">Section 3, &#8220;Batch mode&#8221;</a>)</td>
<td>300</td>
</tr>
<tr>
<td>
<code class="option">--validate</code>
</td>
<td>Perform validation of test results where possible</td>
<td>off</td>
</tr>
</tbody>
</table>
</div>
<p>
Note that numerical values for all <span class="emphasis"><em>size</em></span> options
(like <code class="option">--thread-stack-size</code> 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).
</p>
</div>
<div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="batch_mode"></a>3. Batch mode</h2></div></div></div>
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 <code class="option">--batch</code>
option. You may specify the delay in seconds between the consequent dumps with
the <code class="option">--batch-delay</code> option. Example:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
sysbench --batch --batch-delay=5 --test=threads run
</pre></td></tr></table>
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.
</div>
<div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="test_modes"></a>4. Test modes</h2></div></div></div>
This section gives a detailed description for each test mode available
in SysBench.
<div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="cpu_mode"></a>4.1. <code class="option">cpu</code></h3></div></div></div></div><p>
The <code class="option">cpu</code> 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 <code class="option">--cpu-max-primes</code> option. All calculations are performed using 64-bit integers.
</p><p>
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.
</p><p>
Example:
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
sysbench --test=cpu --cpu-max-prime=20000 run
</pre></td></tr></table><p>
</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="threads_mode"></a>4.2. <code class="option">threads</code></h3></div></div></div></div><p>
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.
</p><p>
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.
</p><p>
The following options are available in this test mode:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--thread-yields</code></td><td>Number of <span class="emphasis"><em>lock/yield/unlock</em></span> loops to execute per each request</td><td>1000</td></tr><tr><td><code class="option">--thread-locks</code></td><td>Number of mutexes to create</td><td>8</td></tr></tbody></table></div><p>
</p><p>
Example:
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
sysbench --num-threads=64 --test=threads --thread-yields=100 --thread-locks=2 run
</pre></td></tr></table><p>
</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="mutex_mode"></a>4.3. <code class="option">mutex</code></h3></div></div></div></div><p>
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.
</p><p>
The following options are available in this test mode:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--mutex-num</code></td><td>Number of mutexes. The actual mutex to lock is chosen randomly before each lock</td><td>4096</td></tr><tr><td><code class="option">--mutex-locks</code></td><td>Number of mutex locks to acquire per each request</td><td>50000</td></tr><tr><td><code class="option">--mutex-loops</code></td><td>Number of iterations for an empty loop to perform before acquiring the lock</td><td>10000</td></tr></tbody></table></div><p>
</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="memory_mode"></a>4.4. <code class="option">memory</code></h3></div></div></div><p>
This test mode can be used to benchmark sequential memory reads or writes. Depending on command line
options each thread can access either a global or a local block for all memory operations.
</p><p>
The following options are available in this test mode:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--memory-block-size</code></td><td>Size of memory block to use</td><td>1K</td></tr><tr><td><code class="option">--memory-scope</code></td><td>
Possible values: <code class="option">global</code>, <code class="option">local</code>. Specifies whether each thread will
use a globally allocated memory block, or a local one.
</td><td>global</td></tr><tr><td><code class="option">--memory-total-size</code></td><td>Total size of data to transfer</td><td>100G</td></tr><tr><td><code class="option">--memory-oper</code></td><td>
Type of memory operations. Possible values: <code class="option">read</code>, <code class="option">write</code>.
</td><td>100G</td></tr></tbody></table></div><p>
</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="fileio_mode"></a>4.5. <code class="option">fileio</code></h3></div></div></div><p>
This test mode can be used to produce various kinds of file I/O workloads. At the <code class="option">prepare</code>
stage SysBench creates a specified number of files with a specified total size, then at the <code class="option">run</code>
stage, each thread performs specified I/O operations on this set of files.
</p><p>
When the global <code class="option">--validate</code> option is used with the <code class="option">fileio</code> 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.
</p><p>
The following I/O operations are supported:
</p><div class="variablelist"><dl><dt><span class="term"><span><strong class="command">seqwr</strong></span></span></dt><dd>sequential write
</dd><dt><span class="term"><span><strong class="command">seqrewr</strong></span></span></dt><dd>sequential rewrite
</dd><dt><span class="term"><span><strong class="command">seqrd</strong></span></span></dt><dd>sequential read
</dd><dt><span class="term"><span><strong class="command">rndrd</strong></span></span></dt><dd>random read
</dd><dt><span class="term"><span><strong class="command">rndwr</strong></span></span></dt><dd>random write
</dd><dt><span class="term"><span><strong class="command">rndrw</strong></span></span></dt><dd>combined random read/write
</dd></dl></div><p>
</p><p>
Also, the following file access modes can be specified, if the underlying platform supports them:
</p><div class="variablelist"><dl><dt><span class="term">Asynchronous I/O mode</span></dt><dd>
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.
</dd><dt><span class="term">Slow <code class="option">mmap()</code> mode</span></dt><dd>In this mode SysBench will use <code class="option">mmap</code>'ed I/O. However, a separate
<code class="option">mmap</code> will be used for each I/O request due to the limitation of 32-bit
architectures (we cannot <code class="option">mmap()</code> the whole file, as its size migth possibly
exceed the maximum of 2 GB of the process address space).
</dd><dt><span class="term">Fast <code class="option">mmap()</code> mode</span></dt><dd>On 64-bit architectures it is possible to <code class="option">mmap()</code> the whole file
into the process address space, avoiding the limitation of 2 GB on 32-bit platforms.
</dd><dt><span class="term">Using <code class="option">fdatasync()</code> instead of <code class="option">fsync()</code></span></dt><dd></dd><dt><span class="term">Additional flags to <code class="option">open(2)</code></span></dt><dd>SysBench can use additional flags to <code class="option">open(2)</code>, such as <code class="option">O_SYNC</code>,
<code class="option">O_DSYNC</code> and <code class="option">O_DIRECT</code>.
</dd></dl></div><p>
</p><p>
Below is a list of test-specific option for the <span><strong class="command">fileio</strong></span> mode:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--file-num</code></td><td>Number of files to create</td><td>128</td></tr><tr><td><code class="option">--file-block-size</code></td><td>
Block size to use in all I/O operations
</td><td>16K</td></tr><tr><td><code class="option">--file-total-size</code></td><td>Total size of files</td><td>2G</td></tr><tr><td><code class="option">--file-test-mode</code></td><td>
Type of workload to produce. Possible values: <code class="option">seqwr</code>, <code class="option">seqrewr</code>,
<code class="option">seqrd</code>, <code class="option">rndrd</code>, <code class="option">rndwr</code>, <code class="option">rndwr</code> (see above)
</td><td><span class="emphasis"><em>required</em></span></td></tr><tr><td><code class="option">--file-io-mode</code></td><td>
I/O mode. Possible values: <code class="option">sync</code>, <code class="option">async</code>, <code class="option">fastmmap</code>,
<code class="option">slowmmap</code> (only if supported by the platform, see above).
</td><td>sync</td></tr><tr><td><code class="option">--file-async-backlog</code></td><td>
Number of asynchronous operations to queue per thread (only for <code class="option">--file-io-mode=async</code>, see above)
</td><td>128</td></tr><tr><td><code class="option"> --file-extra-flags</code></td><td>
Additional flags to use with <code class="option">open(2)</code>
</td><td> </td></tr><tr><td><code class="option">--file-fsync-freq</code></td><td>
Do <code class="option">fsync()</code> after this number of requests (0 - don't use <code class="option">fsync()</code>)
</td><td>100</td></tr><tr><td><code class="option">--file-fsync-all</code></td><td>
Do <code class="option">fsync()</code> after each write operation
</td><td>no</td></tr><tr><td><code class="option">--file-fsync-end</code></td><td>
Do <code class="option">fsync()</code> at the end of the test
</td><td>yes</td></tr><tr><td><code class="option">--file-fsync-mode</code></td><td>
Which method to use for synchronization. Possible values: <code class="option">fsync</code>, <code class="option">fdatasync</code> (see above)
</td><td>fsync</td></tr><tr><td><code class="option">--file-merged-requests</code></td><td>
Merge at most this number of I/O requests if possible (0 - don't merge)
</td><td>0</td></tr><tr><td><code class="option">--file-rw-ratio</code></td><td>
reads/writes ration for combined random read/write test
</td><td>1.5</td></tr></tbody></table></div><p>
</p><p>
Usage example:
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
$ 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
</pre></td></tr></table><p>
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.
</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="database_mode"></a>4.6. <code class="option">oltp</code></h3></div></div></div></div><p>
This test mode was written to benchmark a real database performance. At the <span><strong class="command">prepare</strong></span> stage
the following table is created in the specified database (<code class="option">sbtest</code> by default):
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
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`);
</pre></td></tr></table><p>
Then this table is filled with a specified number of rows.
</p><p>
The following execution modes are available at the <span><strong class="command">run</strong></span> stage:
</p><div class="variablelist"><dl><dt><span class="term">Simple</span></dt><dd><p>
In this mode each thread runs simple queries of the following form:
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen"> SELECT c FROM sbtest WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> </pre></td></tr></table><p>
where <span class="emphasis"><em>N</em></span> takes a random value in range 1..<span class="emphasis"><em>&lt;table size&gt;</em></span>
</p></dd><dt><span class="term">Advanced transactional</span></dt><dd><p>
Each thread performs transactions on the test table. If the test table and database support transactions
(e.g. InnoDB engine in MySQL), then <code class="option">BEGIN</code>/<code class="option">COMMIT</code> statements will be used
to start/stop a transaction. Otherwise, SysBench will use <code class="option">LOCK TABLES</code>/<code class="option">UNLOCK TABLES
</code> 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.
</p>
Depending on the command line options, each transaction may contain the following statements:
<div class="itemizedlist"><ul type="disc"><li>Point queries: <table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT c FROM sbtest WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span></pre></td></tr></table></li><li>
Range queries: <table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT c FROM sbtest WHERE id BETWEEN <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> AND <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span> </pre></td></tr></table></li><li>
Range SUM() queries: <table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT SUM(K) FROM sbtest WHERE id BETWEEN <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> and <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span></pre></td></tr></table></li><li>Range ORDER BY queries:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT c FROM sbtest WHERE id between <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> and <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span> ORDER BY c</pre></td></tr></table></li><li>Range DISTINCT queries:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT DISTINCT c FROM sbtest WHERE id BETWEEN <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> and <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span> ORDER BY c</pre></td></tr></table></li><li>UPDATEs on index column:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">UPDATE sbtest SET k=k+1 WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> </pre></td></tr></table></li><li>UPDATEs on non-index column:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">UPDATE sbtest SET c=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span> </pre></td></tr></table></li><li>DELETE queries:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">DELETE FROM sbtest WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> </pre></td></tr></table></li><li>INSERT queries:<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">INSERT INTO sbtest VALUES (<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>...</em></span>) </pre></td></tr></table></li></ul></div></dd><dt><span class="term">Non-transactional</span></dt><dd><p>
This mode is similar to <span><strong class="command">Simple</strong></span>, but you can also choose the query to run. Note that unlike the
<span><strong class="command">Advanced transactional</strong></span> mode, this one does not preserve the test table between requests, so
you should recreate it with the appropriate <span><strong class="command">cleanup</strong></span>/<span><strong class="command">prepare</strong></span> commands between
consecutive benchmarks.
</p><p>
Below is a list of possible queries:
</p><div class="itemizedlist"><ul type="disc"><li>
Point queries:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">SELECT pad FROM sbtest WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span></pre></td></tr></table></li><li>
UPDATEs on index column:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">UPDATE sbtest SET k=k+1 WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span></pre></td></tr></table></li><li>
UPDATEs on non-index column:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">UPDATE sbtest SET c=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span> WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span></pre></td></tr></table></li><li>
DELETE queries:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">DELETE FROM sbtest WHERE id=<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span></pre></td></tr></table>
The generated row IDs are unique over each test run, so no row is deleted twice.
</li><li>
INSERT queries:
<table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">INSERT INTO sbtest (k, c, pad) VALUES(<span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>N</em></span>, <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>M</em></span>, <span xmlns="http://www.w3.org/1999/xhtml" class="emphasis"><em>S</em></span>)</pre></td></tr></table></li></ul></div><p>
</p></dd></dl></div><p>
</p><p>
Below is a list of options available for the database test mode:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--oltp-test-mode</code></td><td>Execution mode (see above). Possible values: <code class="option">simpe</code> (simple), <code class="option">complex</code> (advanced transactional) and <code class="option">nontrx</code> (non-transactional)</td><td><code class="option">complex</code></td></tr><tr><td><code class="option">--oltp-read-only</code></td><td>
Read-only mode. No <code class="option">UPDATE</code>, <code class="option">DELETE</code> or <code class="option">INSERT</code> queries will be performed.
</td><td>off</td></tr><tr><td><code class="option">--oltp-reconnect</code></td><td>
Re-connect to serveron each transaction.
</td><td>off</td></tr><tr><td><code class="option">--oltp-range-size</code></td><td>Range size for range queries</td><td>100</td></tr><tr><td><code class="option">--oltp-point-selects</code></td><td>
Number of point select queries in a single transaction
</td><td>10</td></tr><tr><td><code class="option">--oltp-simple-ranges</code></td><td>
Number of simple range queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option">--oltp-sum-ranges</code></td><td>
Number of SUM range queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option">--oltp-order-ranges</code></td><td>
Number of ORDER range queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option">--oltp-distinct-ranges</code></td><td>
Number of DISTINCT range queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option">--oltp-index-updates</code></td><td>
Number of index UPDATE queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option">--oltp-non-index-updates</code></td><td>
Number of non-index UPDATE queries in a single transaction
</td><td>1</td></tr><tr><td><code class="option"> --oltp-nontrx-mode</code></td><td>
Type of queries for non-transactional execution mode (see above). Possible values: <code class="option">select</code>,
<code class="option">update_key</code>, <code class="option">update_nokey</code>, <code class="option">insert</code>, <code class="option">delete</code>.
</td><td><code class="option">select</code></td></tr><tr><td><code class="option">--oltp-connect-delay</code></td><td>
Time in microseconds to sleep after each connection to database
</td><td>10000</td></tr><tr><td><code class="option">--oltp-user-delay-min</code></td><td>
Minimum time in microseconds to sleep after each request
</td><td>0</td></tr><tr><td><code class="option">--oltp-user-delay-max</code></td><td>
Maximum time in microseconds to sleep after each request
</td><td>0</td></tr><tr><td><code class="option">--oltp-table-name</code></td><td>
Name of the test table
</td><td>sbtest</td></tr><tr><td><code class="option">--oltp-table-size</code></td><td>
Number of rows in the test table
</td><td>10000</td></tr><tr><td><code class="option">--oltp-dist-type</code></td><td>
<p>
Distribution of random numbers. Possible values: <code class="option">uniform</code> (uniform distribution),
<code class="option">gauss</code> (gaussian distribution) and <code class="option">special</code>.
</p>
<p>
With special distribution a specified percent of numbers is generated in a specified percent of cases (see options below).
</p>
</td><td><code class="option">special</code></td></tr><tr><td><code class="option">--oltp-dist-pct</code></td><td>
Percentage of values to be treated as 'special' (for special distribution)
</td><td>1</td></tr><tr><td><code class="option">--oltp-dist-res</code></td><td>
Percentage of cases when 'special' values are generated (for special distribution)
</td><td>75</td></tr><tr><td><code class="option">--db-ps-mode</code></td><td>
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: <code class="option">disable</code>, <code class="option">auto</code>.
</td><td><code class="option">auto</code></td></tr></tbody></table></div><p>
</p><p>
Also, each database driver may provide its own options. Currently only MySQL driver is available. Below is a list of MySQL-specific options:
</p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="emphasis"><em>Option</em></span></td><td><span class="emphasis"><em>Description</em></span></td><td><span class="emphasis"><em>Default value</em></span></td></tr><tr><td><code class="option">--mysql-host</code></td><td>
<p>
MySQL server host.
</p>
<p>
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.
</p>
</td><td><code class="option">localhost</code></td></tr><tr><td><code class="option">--mysql-port</code></td><td>
MySQL server port (in case TCP/IP connection should be used)
</td><td>3306</td></tr><tr><td><code class="option">--mysql-socket</code></td><td>Unix socket file to communicate with the MySQL server</td><td> </td></tr><tr><td><code class="option">--mysql-user</code></td><td>
MySQL user
</td><td>user</td></tr><tr><td><code class="option">--mysql-password</code></td><td>
MySQL password
</td><td> </td></tr><tr><td><code class="option">--mysql-db</code></td><td>
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.
</td><td>sbtest</td></tr><tr><td><code class="option">--mysql-table-type</code></td><td>
Type of the test table. Possible values: <code class="option">myisam</code>, <code class="option">innodb</code>, <code class="option">heap</code>,
<code class="option">ndbcluster</code>, <code class="option">bdb</code>.
</td><td>innodb</td></tr><tr><td><code class="option">--myisam-max-rows</code></td><td>
MAX_ROWS option for MyISAM tables (required for big tables)
</td><td>1000000</td></tr></tbody></table></div><p>
</p><p>
Example usage:
</p><table xmlns="" border="0" style="background: #E0E0E0;" width="90%"><tr><td><pre class="screen">
$ 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
</pre></td></tr></table><p>
The first command will create a MyISAM table 'sbtest' in a database 'sbtest' on a MySQL server using <code class="option">/tmp/mysql.sock</code> 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.
</p></div>
</div>
</div>
</body>
</html>