From cd14eec87ae870f388ac24c2390e1c608fbed99c Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Mon, 15 Apr 2024 19:50:56 +0000 Subject: doc: note MALLOC_MMAP_THRESHOLD_ as a potential workaround Large string processing + concurrency + caching/memoization really brings out the worst in glibc malloc :< --- examples/public-inbox-netd@.service | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'examples/public-inbox-netd@.service') diff --git a/examples/public-inbox-netd@.service b/examples/public-inbox-netd@.service index 83d2e995..7437f086 100644 --- a/examples/public-inbox-netd@.service +++ b/examples/public-inbox-netd@.service @@ -12,8 +12,11 @@ Wants = public-inbox-netd.socket After = public-inbox-netd.socket [Service] -# An LD_PRELOAD for libjemalloc can be added here. It currently seems +# An LD_PRELOAD for libjemalloc can be added here. It is # more resistant to fragmentation in long-lived daemons than glibc. +# If you're unable to use jemalloc, setting MALLOC_MMAP_THRESHOLD_ +# to a lower value (e.g. 131072) but that may also require increasing +# the sys.vm.max_map_count sysctl. Environment = PI_CONFIG=/home/pi/.public-inbox/config \ PATH=/usr/local/bin:/usr/bin:/bin \ TZ=UTC \ -- cgit v1.2.3-24-ge0c7