[SERVER-24268] Investigate jemalloc as alternative to tcmalloc Created: 24/May/16 Updated: 01/Feb/19 Resolved: 19/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Gorrod | Assignee: | Alexander Gorrod |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
The server currently uses tcmalloc by preference. There are some known issues with tcmalloc fragmentation and memory release semantics (see |
| Comments |
| Comment by Alexander Gorrod [ 19/Jul/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
I’ve run a lot of tests comparing the performance and memory consumption characteristics of TCMalloc (current default) and JEMalloc. The following comment summarizes my findings. Tl;dr JEMalloc doesn’t currently deliver enough advantages to warrant the risk of switching default allocators. If we identify specific use cases that could benefit from a pool based memory allocator it is worth reconsidering the change. I ran a number of different tests to assess the behavior differences. I ran full sets of correctness tests via both WiredTiger Jenkins testing and MongoDB Evergreen testing - none of which showed any issues with JEMalloc. Following is a quick summary of the performance test suites:
Note: how much difference the purge:decay setting makes for JEMalloc - without that setting JEMalloc is not a viable alternative. Overall JEMalloc would be a reasonable substitute for TCmalloc in MongoDB, but the differences are not compelling enough to warrant a change at this stage. If we believe that a pool based allocator could benefit us in the future, it’s worth considering again. One further note: The patch attached to this ticket adds JEMalloc into the MongoDB tree as an alternative allocator, enabled via "--allocator=jemalloc", it also exposes several basic JEMalloc allocator statistics and configuration options via MongoDB. i.e: if someone is picking this work up again, I believe it's worth reviewing the patch on this ticket before jumping in. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Gorrod [ 18/Jul/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
A patch against MongoDB that adds JEmalloc as a compile time allocator option. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Gorrod [ 18/Jul/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
I found that there is a compile/run option to JEMalloc that makes it behave more sensibly for our needs, which is "purge:decay". I'll report soon on comparisons between JEMalloc and tcmalloc - all measurements including JEMalloc are based on the 4.2.1 release built from source with "purge:decay" enabled. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alexander Gorrod [ 10/Jun/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
I've been running a YCSB workload comparing builds of MongoDB that use jemalloc to the built-in tcmalloc. The YCSB configuration I've been running is:
Which is designed to stress the memory allocator. The jemalloc options I've tried configuring are:
I have actual results, and will quantify the results next week, but wanted to save an overview here mostly for myself in the mean time. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Eric Milkie [ 24/May/16 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
|