v0.4.2 — opt jemalloc out of THP

v0.4.2

Operational fix: opt jemalloc out of Transparent Huge Pages.

What changed

deploy(systemd): opt jemalloc out of THP via _RJEM_MALLOC_CONF=thp:never
(0882771)

Adds Environment=_RJEM_MALLOC_CONF=thp:never to the systemd unit
shipped in deploy/ergo-node-rust.service. Operators installing via
the .deb package automatically get the new unit; manual installs
should pick up the change in the unit file.

Why

Observed on mainnet at-tip after a 49k-block snapshot replay: RSS
climbed monotonically while jemalloc-allocated stayed flat at ~1.6 GB.
Six hours into at-tip operation, RSS was at 6.8 GB and growing
~300 MB/h with no actual program memory pressure. /proc smaps
showed 5.95 GB of 7.24 GB anon RSS in AnonHugePages.

Mechanism: with kernel transparent_hugepage/enabled=always (Debian
default), jemalloc's madvise(MADV_DONTNEED) calls cannot effectively
return memory. Huge pages are 2 MB contiguous; the kernel won't
reclaim partial regions without splitting first. Result: jemalloc's
books say "purged"; kernel keeps full 2 MB resident; RSS grows
monotonically.

thp:never makes jemalloc explicitly madvise(MADV_NOHUGEPAGE) its
arenas, so the kernel respects granular purges. Verified on mainnet:
RSS dropped from 6.81 GB to 1.45 GB on the next restart and stays
within ~80 MB of jemalloc-allocated thereafter.

The _RJEM_ prefix is required by tikv-jemallocator (jemalloc symbols
are mangled — standard MALLOC_CONF is silently ignored).

Operators upgrading from v0.4.1

If your v0.4.1 node has been at tip for a while and RSS is much higher
than jemalloc-allocated (compare via the /debug/memory endpoint), a
restart on v0.4.2 will reset RSS to the new baseline. No state migration
or data loss — just systemctl restart.

Submodule pointers

Unchanged from v0.4.1.

Commits

119cf0f chore: release v0.4.2
0882771 deploy(systemd): opt jemalloc out of THP via _RJEM_MALLOC_CONF=thp:never

Full Changelog: v0.4.1...v0.4.2