From c372f2c24d64435c303024f103aac99e37ffb0b4 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Tue, 14 May 2024 06:38:06 +0000 Subject: doc: limit jemalloc recommendation to 64-bit systems My 32-bit server seems less happy with jemalloc; likely since munmap is creating holes and it's not using sbrk by default. jemalloc seems to need large VM space (not actual memory) to work well, and that isn't a possibility for constrained 32-bit systems. --- Documentation/public-inbox-tuning.pod | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation/public-inbox-tuning.pod') diff --git a/Documentation/public-inbox-tuning.pod b/Documentation/public-inbox-tuning.pod index 892ee0f2..b56c2b10 100644 --- a/Documentation/public-inbox-tuning.pod +++ b/Documentation/public-inbox-tuning.pod @@ -166,9 +166,10 @@ capacity planning. Bursts of small object allocations late in process life contribute to fragmentation of the heap due to arenas (slabs) used internally by Perl. glibc malloc users should use C to reduce -fragmentation from the sliding mmap window. jemalloc (tested as an -LD_PRELOAD on GNU/Linux) also reduces fragmentation compared to an -unconfigured glibc malloc in long-lived processes. +fragmentation from the sliding mmap window. On 64-bit systems, jemalloc +(tested as an LD_PRELOAD on GNU/Linux) reduces fragmentation at the +expense of VM space. 32-bit systems may be better off sticking with +glibc and MALLOC_MMAP_THRESHOLD_. =head2 Other OS tuning knobs -- cgit v1.2.3-24-ge0c7