-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.6.2
-
Component/s: WiredTiger
-
Product Performance
-
Linux
-
-
Dev Tools 2019-05-06, Dev Tools 2019-04-22
-
(copied to CRM)
The changes described in SERVER-20306 eliminated a common source of memory fragmentation, but it can still occur for other reasons. Here's an example from a node undergoing initial sync:
Over time
- allocated memory never exceeds 8 GB
- but heap size and resident memory reach nearly 14 GB
- this is due to an accumulation of pageheap_free_bytes
A common cause of this is a shifting distribution of allocated memory sizes, which leaves free pages dedicated to one size of buffer unable to be used for new memory requests because they are for a different size buffer.
Setting TCMALLOC_AGGRESSIVE_DECOMMIT can address this issue by causing tcmalloc to aggressively return the free pages to the o/s where they can then be re-used by tcmalloc to satisfy new memory requests. However can have an unacceptable negative performance impact. Is there a tweak to tcmalloc that can give us better behavior for workloads like this?
- is duplicated by
-
SERVER-37541 MongoDB Not Returning Free Space to OS
- Closed
- related to
-
SERVER-39325 Add support for "allocator=jemalloc"
- Backlog
-
SERVER-35046 Add parameter to set tcmalloc aggressive decommit
- Closed
-
SERVER-31417 Improve tcmalloc when decommitting large amounts of memory
- Backlog
- mentioned in
-
Page Loading...