MongoDB benchmark: sysbench-mongodb IO-bound workload comparison

MongoDB benchmark: sysbench-mongodb IO-bound workload comparison

PREVIOUS POST
NEXT POST

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.

PREVIOUS POST
NEXT POST

Share this post

Comments (5)

  • Peter Zaitsev Reply

    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 🙂

    July 14, 2015 at 10:43 am
  • Mark Callaghan Reply

    Bugs are open for WiredTiger in the JIRA. They are making progress, but there is more to be done.
    https://jira.mongodb.org/secure/Dashboard.jspa

    July 14, 2015 at 11:30 am
  • Leif Walsh Reply

    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?

    July 14, 2015 at 12:14 pm
  • Vadim Tkachenko Reply

    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.

    July 14, 2015 at 12:20 pm
    • Leif Walsh Reply

      Vadim,

      Cool. Sounds about right. I’ll be interested to see your data results.

      July 14, 2015 at 12:23 pm

Leave a Reply