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:
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.
About the Author
Vadim TkachenkoVadim 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. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. 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 🙂
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
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.
Vadim,
Cool. Sounds about right. I’ll be interested to see your data results.