# Two XRP Ledger Validators Show Up to 23% Lower Process Memory

By Simon Yoon

Canonical URL: https://www.tokenpost.com/news/technology/51347
Published: 2026-11-08T04:24:47.000Z
Updated: 2026-11-08T04:24:47.000Z
Section: Technology

> A glibc heap-trimming change is active in `xrpld` 3.3.0 and later; a separate five-hour fixed-load test found lower RSS on validator and client-handler nodes.

Two Ripple-operated XRP Ledger (XRPL) validators recorded 13% and 23% lower process memory after moving from xrpld 3.2.0 to 3.3.0, while separate tests found smaller reductions under controlled loads.

Average resident set size (RSS) fell from 20.1 GiB to 17.4 GiB on the validator outside the default UNL group, a 2.7 GiB drop. On the dUNL validator, it declined from 19.4 GiB to 15.0 GiB, a 4.4 GiB reduction. RSS measures memory held by an individual process; these readings do not represent total host memory or a network-wide change.

Each measurement window began with a fresh process start, and the averages exclude the first five days, when memory use had not yet reached a plateau. The xrpld 3.2.0 window ran for 44 days, from June 16 to July 31, 2026. The 38-day 3.3.0 window began Aug. 7, after an intervening week that included a hotfix release and an unrelated network incident was excluded. Version 3.3.0 was released Aug. 6.

The software calls glibc’s malloc_trim after a cache sweep, asking the allocator to return unused heap memory to the kernel. For builds using glibc, xrpld enables heap trimming from version 3.3.0 onward; builds using other allocators do not use the change. The mainnet comparison spans versions with changes beyond heap trimming, so it does not isolate the effect of the trim.

A separate five-hour fixed-load test on a five-validator performance network found RSS was 2.58 GB, or 14.8%, lower on validator nodes with trimming enabled. On client-handler nodes, it was 3.33 GB, or 18.2%, lower. Selected consensus-timing measures showed no detected changes, including ledger-close intervals, voting duration and transaction-set acquisition time.

In a separate lab comparison, the trimmed build had RSS of 18.3 GiB after 24 hours, compared with 32.9 GiB for the baseline, a 44% difference. Each build was run once. RippleX engineer Valentin Balaschenko said, “This variation exceeds what can be explained by measurement differences alone and requires further investigation.”