Node worker RSS 2.5x its data after a big native load: glibc malloc arenas; MALLOC_ARENA_MAX=2 fixes
Symptom: a Node child-process worker (child_process.fork) whose native addon loads a large data set through a third-party C/C++ library, copies it into its own compact store (9 B per item), then frees the library's buffers, kept RSS at ~22.6 B per item after the first big load (~265 MB extra for ~20 M items). The second load of the same size added only ~8.7 B per item, so it looked like a one-time high-water mark.
What it was NOT: trim/mmap tuning had no effect (GLIBC_TUNABLES=glibc.malloc.trim_threshold=0:glibc.malloc.mmap_threshold=65536 gave 22.7 B per item). The shrink_to_fit/reserve copies in the store code were already transient.
What it was: the freed memory sits in extra glibc malloc arenas, probably created by the library's own threads, and is not returned to the OS. GLIBC_TUNABLES=glibc.malloc.arena_max=1 or =2 (or MALLOC_ARENA_MAX=1/2) dropped the first load to 9.2 B per item, with load time unchanged at arena_max=2 (6.4 vs 6.5 s; 1 arena was ~10% slower).
Fix: fork the workers with env { ...process.env, MALLOC_ARENA_MAX: process.env.MALLOC_ARENA_MAX || '2' }. glibc reads it at process start, so it has to go in the child's env (or a launcher script's export for the parent process). A process can't apply it to itself after it has started. To test the wiring without glibc, have a stub addon log process.env.MALLOC_ARENA_MAX from every forked process kind.
How to find it fast: run the same load under arena_max=1 and under trim/mmap tunables. If only the arena cap removes the excess, it's arena retention, not your own buffers.
Independent re-measure by a reviewer on a large native load (1 worker, 2 runs each): worker RSS 828 -> 577 MB, PSS 794 -> 543 MB (-30%), load time unchanged within noise (about 6.6-6.8 s both ways). Two practical gotchas: (1) set it in the env at every fork/spawn site, not just the top-level launcher. A coordinator started directly (not via the launcher) lacked it while its workers had it, because only the spawn path added it. (2) Only default it when unset (env.MALLOC_ARENA_MAX ?? '2'), so a user's explicit value (for example 8 for a thread-heavy workload) wins. Test both: an unset env gives 2 in /proc/<pid>/environ of every child, and a preset value is passed through unchanged.