sysbench 说明

   wily  ( 1 )  sysbench.1.gz
Provided by:  sysbench_0.4.12-1.1_i386  

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.  >>sysbench 是一款模块化，跨平台，多线程的压力测试工具。可用用来评估在高负载下数据库服务器的操作系统操作是否合适

       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:  sysbench支持以下几种测试模式

       ·   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. >>sysbench的涉及十分简单，它通过发起指定数量的线程并行的执行相应请求。这些请求产生的实际的负载情况跟你指定的模式有关。你可以通过指定总的请求数，也可通过以指定总的测试时间，或者同时指定两者，来限制测试任务的时间。

       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 >>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): >>在prepare阶段，会在指定的db下建立如下结构的sbtest表(我们也可以通过--oltp-table-name指定表名，我们也可以指定多个表--oltp-num-tables=10，多个表时即在sbtest加上数字做后缀)

                        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. >>在prepare阶段测试表会被插入指定量的数据(--oltp-table-size=10000000)

           The following execution modes are available at the run stage:  >>下面是在run阶段可以选择的执行模式--oltp-test-mode={simple,complex,nontrx}

           Simple
               In this mode each thread runs simple queries of the following form: >>在simple 模式在每个线程只会执行如下所示的简单查询

                    SELECT c FROM sbtest WHERE id=N

               where N takes a random value in range 1..<table size> 

     >>N在1和--oltp-table-size所指定数值间随机取值


           Advanced transactional >>Advanced transactional  指的即是--test=complex模式
               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.  >>如果测试表支持事务(如innodb表)，那么使用begin和commit开启和结束事务。否则的话使用lock table和unlock tables开始和结束一个语句。如果一个事务中对测试表进行了删除操作，那么在同一个事务中会进行相同行数的插入操作。所以complex测试模式不会破坏测试表中的数据，可以进行一次prepare，多次run

               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 >>nontrx测试模式
               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.  >>从名字上看很容易让人误解，认为这个是非事物测试，但是它也可以进行dml操作，在--oltp-test-mode=指定为nontrx情况下，可以通过--oltp-nontrx-mode参数指定{select, update_key, update_nokey, insert, delete}，默认值是select(nontrx模式下测试不会像complex那样保证测试表的数据量不变，所以在进行连续测试的时候，注意进行cleanup和prepare操作)

               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)  >>测试时不进行update，delete或者insert操作(默认值为off)

           --oltp-range-size
               Range size for range queries (default: 100)  >>指定范围查询的范围大小，默认值为100

           --oltp-point-selects
               Number of point select queries in a single transaction(default: 10)  >>每个事物中单点查询的数量，默认值为10

           --oltp-simple-ranges
               Number of simple range queries in a single transaction(default: 1)  >>每个事物中简单范围查询的数量，默认值为1

           --oltp-sum-ranges
               Number of SUM range queries in a single transaction (default:1)  >>每个事物中统计范围查询的数量，默认值为1

           --oltp-order-ranges
               Number of ORDER range queries in a single transaction (default:1)  >>每个事物中排序范围查询的数量，默认值为1

           --oltp-distinct-ranges
               Number of DISTINCT range queries in a single transaction(default: 1)  >>每个事物中去重排序范围查询的数量，默认值为1

           --oltp-index-updates
               Number of index UPDATE queries in a single transaction(default: 1)  >>每个事物中索引更新的数量，默认值为1

           --oltp-non-index-updates
               Number of non-index UPDATE queries in a single transaction(default: 1)  >>每个事物中非索引更新的数量，默认值为1

           --oltp-nontrx-mode
               Type of queries for non-transactional execution mode (seeabove). Possible values: select, update_key, update_nokey,insert, delete. (default: select)

               >>在--test=nontrx模式下 可以通过oltp-nontrx-mode选项指定如上几种测试项,查询，索引更新，非索引更新，插入，删除，默认值为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)  >>指定测试表名，默认值为sbtest(如果指定了--oltp-num-tables，那么默认测试表名为sbtest，sbtestN)

           --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.