Hi, Monty asked me to do a quick check how MariaDB performs with jemalloc. This is in the light of the upcoming integration of TokuDB into the MariaDB tree. TokuDB requires jemalloc.
While I did use tcmalloc in the connect speed benchmarks with good results, I did no use jemalloc before. This article from Percona http://www.mysqlperformanceblog.com/2013/03/08/mysql-performance-impact-of-memory-allocators-part-2/ suggests that jemalloc and tcmalloc perform very comparable, but also that jemalloc shows a regression in 3.2.0 and later. The benchmark I used is sysbench OLTP ro, 16 tables, data fitting into buffer pool. I used the new 64 (virtual, 32 real) core machine and compared 4 different malloc implementations as below: OLTP ro transactions per second relative to glibc malloc ---------------------------------------------------------------------- Threads jemalloc-3.3.1 glibc malloc tcmalloc jemalloc-3.1.0 4 +3.2% +0.0% +11.6% +61.9% 8 +0.9% +0.0% -2.3% +8.0% 16 +9.6% +0.0% +4.7% +12.9% 32 +1.8% +0.0% +0.9% +5.8% 64 -5.1% +0.0% +2.1% +5.4% 128 -4.8% +0.0% +0.2% +4.5% 256 -4.2% +0.0% +0.7% +5.0% 512 -13.3% +0.0% +1.8% +4.1% (more data in attached spread sheet) Observations: - the effect is rather limited - jemalloc 3.1.0 clearly wins - jemalloc 3.3.1 performs bad at higher concurrency Conclusion It's fine to build MariaDB with jemalloc in the future. However we mustn't use jemalloc-3.3.1, but rather jemalloc-3.1.0. XL
OLTP-malloc-series40.ods
Description: application/vnd.oasis.opendocument.spreadsheet
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
