[SERVER-24483] Consider utilising a pool based memory allocator Created: 09/Jun/16 Updated: 06/Dec/22 Resolved: 19/Jul/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | WiredTiger |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Gorrod | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
There are known issues with memory fragmentation in the MongoDB 3.2 release when running certain workloads (tracked in One way we may be able to reduce the amount of fragmentation would be to use separate allocator pools for different allocations. Especially within WiredTiger, where there is some knowledge about the expected lifespan of different allocations. |
| Comments |
| Comment by Alexander Gorrod [ 19/Jul/16 ] |
|
The analysis of JEMalloc didn't deliver enough evidence to switch default allocators in MongoDB. Since tcmalloc doesn't support a pool based allocation scheme, we can't pursue this method of reducing allocator fragmentation for now. |