loadtest.appby LoadFocus

Guides

How to use sysbench for CPU, disk and MySQL benchmarks

6 min read

sysbench is an open source, multi-threaded benchmark tool built on LuaJIT that ships with CPU, memory, file I/O, thread and mutex tests, plus OLTP scripts for MySQL and PostgreSQL. Tests that need data follow the same lifecycle: prepare creates the test files or tables, run executes the benchmark for a set time or number of events, and cleanup removes the data; the CPU and memory tests need only run. It measures one machine or one database server, so it cannot tell you how your application behaves under real user traffic.

We have not run sysbench for this guide. The facts come from its README and source code on GitHub’s master branch, checked on 31 October 2026, and the advice is ours.

Topicsysbench
LicenceGPLv2
Written inC, with LuaJIT for scripts
Latest release1.0.20 (24 April 2020)
Latest commit9 March 2025
Built-in testscpu, memory, fileio, threads, mutex
Database scriptsEight oltp_* scripts, bulk_insert, two select_random_*
Database driversMySQL (default), PostgreSQL
PlatformsLinux, macOS; Windows through WSL

Is sysbench still maintained?

Only lightly. The latest release, 1.0.20, came out in April 2020; the master branch has had occasional commits since, none of them released, the most recent in March 2025.

The 1.0.20 release is dated 24 April 2020. The commit history shows changes such as a uniform default for --rand-type (2020), an upstream LuaJIT (2023) and MariaDB client support (2023), then four build commits on 9 March 2025 (checked on 31 October 2026). The README’s package repositories are updated on each release, so those changes need a build from source.

How does a sysbench run work?

You name a test and a command: sysbench [options] [testname] [command]. The test is a built-in, a bundled Lua script or your own script, and the command is usually prepare, run, cleanup or help.

The README says prepare creates files for fileio or fills the database for the OLTP scripts, cleanup removes that data, and sysbench <testname> help lists a test’s options. A disk test:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

The fileio source lists the modes seqwr, seqrewr, seqrd, rndrd, rndwr and rndrw, with 2 GB of files by default. Files that fit in memory can be served from the page cache, so make the set larger than RAM to measure the disk.

How do you benchmark CPU and memory with sysbench?

Use sysbench cpu run and sysbench memory run. The CPU test reports events per second, where one event checks every number up to a limit for primality, and the memory test reports operations and MiB transferred per second.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

The CPU test sets --cpu-max-prime to 10000 by default, and the memory test takes a block size, a total size, read or write operations and sequential or random access (checked on 31 October 2026). Compare only runs with identical settings.

How do you benchmark MySQL or PostgreSQL with sysbench?

Pick a bundled OLTP script, fill the tables with prepare, run transactions from several threads with run, then drop the tables with cleanup. MySQL is the default driver; PostgreSQL needs --db-driver=pgsql and a build with PostgreSQL support.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

The shared OLTP script creates one table of 10,000 rows unless you pass --tables and --table-size. In oltp_read_write, each transaction runs 10 point selects, four range queries, two updates and a delete plus insert inside BEGIN and COMMIT (checked on 31 October 2026). Make the data larger than the server’s buffer pool if you want disk reads in the result.

Which sysbench options matter most?

--threads and --time set the size and length of a run, --rate sets a target event rate, and --report-interval, --percentile and --histogram decide what you see.

  • --threads: worker threads, 1 by default.
  • --time: seconds, 10 by default, 0 for no limit. --events caps the event count, and both limits apply, so pair it with --time=0.
  • --warmup-time: runs with statistics off first, so cold caches do not skew the result. Master only: the 1.0.20 release does not have it.
  • --rate: average events per second across all threads; 0, the default, means as fast as possible.
  • --report-interval: per-interval figures every N seconds, to expose stalls.
  • --percentile: the latency percentile to report, 95 by default.
  • --histogram: a latency histogram at the end, defined in sb_logger.c.

Does sysbench use a closed or an open workload model?

Closed by default: a fixed number of threads each start the next event when the previous one ends, so a slow server receives fewer events. With --rate, events arrive on their own schedule, which is closer to an open model.

Our article on the open vs closed workload model explains why that changes what a benchmark measures. In the default mode, a stall also delays the events that would have started during it, and those delays never reach the latency figures: coordinated omission. The main source file shows that --rate queues events at exponentially distributed intervals, adds each event’s queue wait to its latency, and stops with an “event queue is full” error when the threads cannot keep up (checked on 31 October 2026).

How do you read sysbench output?

Start with throughput: events per second, or transactions and queries per second for the OLTP scripts. Then read the latency block in milliseconds: minimum, average, maximum, the chosen percentile (95th by default) and the sum.

The 1.0.20 release prints a “General statistics” block with the total time and total number of events in place of “Throughput”. The field names below come from the database report code and the main source file on master, with the values left out:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

A 95th percentile ignores the slowest one in twenty events. Set --percentile=99 or add --histogram when the tail matters; our guide to tail latency explains why.

When is sysbench the wrong tool?

When your question is about your application. A CPU score shows how fast one machine checks primes, and an OLTP run measures the database server with sysbench’s own tables and queries, without your schema, connection pool or network path.

  • Choose pgbench for PostgreSQL-native tests: the PostgreSQL documentation describes a default scenario loosely based on TPC-B, plus custom script files (checked on 31 October 2026).
  • Choose HammerDB for TPC-C-style tests: its documentation covers the TPROC-C workload, derived from TPC-C, for SQL Server, Db2, Oracle, PostgreSQL, MariaDB and MySQL (checked on 31 October 2026).
  • Choose JMeter with its JDBC Request sampler to mix SQL and HTTP in one test plan; the database test plan guide says the driver .jar goes into JMeter’s lib folder.

LoadFocus, which publishes this site, does not run sysbench and cannot connect to MySQL or PostgreSQL itself. It runs JMeter test plans and k6 scripts from 25 cloud regions against the web or API layer in front of the database. A useful pairing is a sysbench run to size the database server, then a load test of the application to see whether real requests reach that limit.

FAQ

Is sysbench still maintained? Lightly. The latest release is 1.0.20 from 24 April 2020. The master branch has received occasional commits since, none of them in a release, the most recent on 9 March 2025.

What does the 95th percentile in sysbench output mean? It is the latency, in milliseconds, within which 95% of events finished. 95 is the default of the --percentile option, and you can set another value such as 99.

Can sysbench benchmark PostgreSQL? Yes. The bundled OLTP scripts run against PostgreSQL with --db-driver=pgsql when sysbench was built with PostgreSQL support.

Can LoadFocus run sysbench? No. LoadFocus runs JMeter test plans and k6 scripts against websites and APIs from 25 cloud regions, and it does not connect to MySQL or PostgreSQL directly.

The technical claims in this article have not been independently reviewed.

LoadFocus team
Written by the LoadFocus team, the people behind a cloud load testing service.