Is it recommended to use jemalloc in Node.js ?

[theanarkh]

What is the problem this feature will solve?

I saw some issues earlier about using jemalloc, has anyone done this in a production environment ? thanks !

What is the feature you are proposing to solve the problem?

none

What alternatives have you considered?

No response

[marco-ippolito]

Moving this to discussion as it's for gathering feedback

[laurisvan]

This answer is a bit late, but we recently switched from musl malloc to jemalloc. We suspected memory fragmentation as the reason for node.js garbage collection failing to a OOM kill. After switching we have not seen such OOM kills yet.

[laurisvan]

Update on this one - jemalloc is not a silver bullet here. We have seen OOM kills since that and cannot confirm it certainly would work better. Then again, we are running Alpine containers, and musl malloc therein provenly had several problems. That is not a node.js specific problem, though.

Since Jemalloc is no longer officially maintained (https://jasone.github.io/2025/06/12/jemalloc-postmortem/), a better alternative might be mimalloc or tcmalloc.

[kaluarachchiteshan]

Yes, people use jemalloc with Node.js in production, but it is not bundled or officially recommended by Node.js. It's an optional, workload-dependent tweak.

When it can help

• Long-running Linux services whose memory (RSS) keeps growing even though the JS heap is stable. This is often caused by glibc malloc fragmentation, especially with many threads, Buffers, or native addons.
• Workloads with heavy native allocations (streams, crypto, image processing, etc.).

How to try it (Linux, no code changes)

# Debian/Ubuntu
apt-get install -y libjemalloc2

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 node app.js

In a Dockerfile:

RUN apt-get update && apt-get install -y libjemalloc2
ENV LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2

(The library path differs by distro and architecture, e.g. aarch64-linux-gnu on ARM.)

Cheaper things to try first

• Set MALLOC_ARENA_MAX=2 (or a small number) to reduce glibc arena fragmentation.
• Check whether the growth is really native memory and not a JS leak: compare process.memoryUsage() (rss vs heapUsed) or use heap snapshots.
• Alpine/musl uses a different allocator, which can behave differently from glibc.

Caveats

• Benchmark with your own workload. Gains depend on the allocation pattern and may be small or none.
• It's an unsupported configuration, so if you hit crashes or odd behavior, reproduce without LD_PRELOAD before reporting a bug to Node.js.
• Check the current maintenance status of the jemalloc project before standardizing on it. Alternatives like tcmalloc or mimalloc can also be preloaded the same way.
• Use MALLOC_CONF (e.g. background_thread:true, dirty_decay_ms) to tune how aggressively memory is returned to the OS.

Hope this helps. If you share your use case (memory growth pattern, OS, container setup), people can give more specific advice.