Twee XRP Ledger validators gebruiken tot 23% minder werkgeheugen

Wat er gebeurde

Na upgrade van xrpld 3.2.0 naar 3.3.0 daalde de gemiddelde RSS op twee validators met respectievelijk 13% en 23%. De RSS van een validator buiten de default UNL-groep viel van 20,1 GiB naar 17,4 GiB, een daling van 2,7 GiB. Op de dUNL-validator daalde de RSS van 19,4 GiB naar 15,0 GiB, een vermindering van 4,4 GiB.

De metingen begonnen telkens met een nieuw gestart proces. De gemiddelden sluiten de eerste vijf dagen uit, toen het geheugenverbruik nog niet stabiel was. De 3.2.0-venster liep 44 dagen van 16 juni tot 31 juli 2026. De 3.3.0-venster begon op 7 augustus 2026 en liep 38 dagen. Versie 3.3.0 werd op 6 augustus uitgebracht. Een tussenliggende week met een hotfix en een apart netwerkincident is weggelaten.

In xrpld 3.3.0 roept de software glibc’s malloc_trim aan na een cache sweep. Dit vraagt de allocator om ongebruikt heap-geheugen terug te geven aan de kernel. Alleen builds die glibc gebruiken hebben deze heap-trimming ingeschakeld. Builds met andere allocators gebruiken de verandering niet.

De vergelijking op mainnet omvat versies met meer wijzigingen dan alleen heap-trimming. Daardoor kan die vergelijking de specifieke invloed van de trim niet isoleren. RSS meet het geheugen dat een individueel proces vasthoudt. Deze cijfers geven niet het totale geheugen van de host of een netwerkbrede wijziging weer.

Een aparte vijf uur durende fixed-load test op een vijf-validator performance-netwerk liet ook lagere RSS zien. Op validator-nodes met trimming was RSS 2,58 GiB of 14,8% lager. Op client-handler nodes was het 3,33 GiB of 18,2% lager. Geselecteerde consensus-timingmetingen toonden geen veranderingen. Dat geldt voor ledger-close intervallen, votingduur en de tijd om transaction-sets te verkrijgen.

In een laboratoriumvergelijking had de trimmed build na 24 uur RSS van 18,3 GiB, tegenover 32,9 GiB voor de baseline. Dat is een verschil van 44%. Elke build werd één keer gedraaid. Een RippleX-engineer zei dat die variatie groter is dan wat meetverschillen alleen kunnen verklaren en genoemd werd dat nader onderzoek nodig is.

Waarom dit telt

Lagere procesgeheugenwaarden kunnen betekenen dat validators minder geheugen nodig hebben of efficiënter werken. De bevindingen zijn echter niet eenduidig en de mainnetdata laten niet zien welk deel van de winst door heap-trimming komt. Beleggers in XRP kunnen dit nieuws volgen voor ontwikkelingen rond netwerk-efficiëntie, maar de impact op het netwerk en kosten is nog niet definitief vastgesteld.