Buy Percona ServicesBuy Now!

MongoDB benchmark: sysbench-mongodb IO-bound workload comparison

 | July 14, 2015 |  Posted In: Benchmarks, MongoDB


In this post I’ll share the results of a sysbench-mongodb benchmark I performed on my server. I compared MMAP, WiredTiger, RocksDB and TokuMXse (based on MongoDB 3.0) and TokuMX (based on MongoDB 2.4) in an IO-intensive workload.

The full results are available here, and below I’ll just share the summary chart:

MongoDB benchmarks: sysbench-mongodb IO-bound workload

I would like to highlight that this benchmark was designed to emulate a heavy IO load on a (relatively) slow IO subsystem. This use case, I believe, is totally valid and represents frequently used “cloud” setups with limited memory and slow IO.

The WiredTiger engine, as B-Tree based, is expected to perform worse comparing to RocksDB and Toku Fractal Trees, which, are designed to handle IO-intensive workloads. My assumption is that WiredTiger will perform better (or even outperform others) for CPU intensive in-memory workloads (see for example Mark Callaghan’s results). Also WiredTiger is expected to perform better with faster storage.

Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.


  • Interesting….

    It looks like both TokuMX/TokuSE and WiredTiger has same problems Innodb used to have few years ago – very uneven performance at sustained high load. I wonder who will fix the problems first 🙂

  • I know of someone working on adding something like InnoDB’s fuzzy checkpointing to the fractal tree engine.

    Vadim: why did you choose a fanout of 128 for the toku engines?

  • Leif,

    I am going to write on fanout soon. The optimal choice seems to be workload depended, but what I found out, with a small fanout, a lot of cache memory wasted by non-leaf pages and messages in them, which results in Fractal Tree performing a lot of unnecessary IOs by writing huge pages (4MB) to disk, evicting them and bringing new huge (4MB) pages from disk.

Comments are closed