We read the resident memory (VmRSS) of 33 XDC nodes on three hosts in eight read-only samples from 2026-11-14 19:20 UTC to 2026-11-15 04:07 UTC. The xOne nodes on net2040 used 0.08 to 0.62 GiB. The largest numbers, up to 13 GiB, belong to Apothem nodes, and for two of them most of that memory is file-backed pages of the database, not the client's own heap. This post gives the table and explains how to read it.
The probe is read-only: VmRSS from /proc/<pid>/status, the head from eth_blockNumber. Hosts are named A, B and C. Host A is the 20-core host that also runs builds. For the probe method see the fleet snapshot of 2026-11-15.
How much memory does each node use?
Resident memory at 04:07 UTC, and the lowest and highest of the eight samples, in GiB. All nodes were at or near the tip, except the Apothem reth-xdc minimal node, which was about 44,900 blocks behind (its catch-up).
net2040
| Host | Client and mode | RSS | Range |
|---|---|---|---|
| B | reth-xdc archive | 2.74 | 2.68-2.74 |
| C | reth-xdc full | 1.50 | 1.50-1.58 |
| C | besu-xdc snap (Bonsai) | 1.34 | 1.31-1.34 |
| B | geth-XDC full (reference) | 1.06 | 1.06-1.09 |
| C | nethermind-xdc archive | 0.92 | 0.92-1.05 |
| B | nethermind-xdc, memory pruning (3 nodes) | 0.80-0.89 | 0.69-0.92 |
| B | besu-xdc full (Bonsai) | 0.85 | 0.74-0.85 |
| C | nethermind-xdc full (hybrid) | 0.72 | 0.68-0.72 |
| B | xOneRS full | 0.62 | 0.57-0.62 |
| A | xOneTS full | 0.31 | 0.28-0.33 |
| C | xOneRS minimal | 0.22 | 0.22-0.22 |
| A | xOneRS full | 0.20 | 0.08-0.26 |
| A | xOneRS archive | 0.20 | 0.13-0.57 |
| C | xOneRS fast | 0.20 | 0.20-0.20 |
| A | xOnePy snap | 0.12 | 0.06-0.12 |
| A | xOnePy minimal | 0.12 | 0.06-0.12 |
| A | xOneC archive | 0.12 | 0.09-0.66 |
| A | xOneC full | 0.10 | 0.07-0.23 |
| A | xOneC snap | 0.09 | 0.06-0.10 |
| A | xOneC minimal | 0.08 | 0.06-0.09 |
Apothem
| Host | Client and mode | RSS | Range |
|---|---|---|---|
| C | xOneC snap | 13.07 | 9.14-14.11 |
| B | reth-xdc full | 11.63 | 7.24-12.61 |
| B | geth-XDC snap (reference) | 5.98 | 5.93-6.00 |
| C | reth-xdc minimal | 5.43 | 5.38-5.44 |
| C | erigon-xdc minimal | 3.51 | 2.64-4.18 |
| B | besu-xdc snap (Bonsai) | 2.22 | 2.11-2.22 |
| C | nethermind-xdc hybrid | 1.98 | 1.54-1.99 |
| B | nethermind-xdc hybrid | 1.79 | 1.52-2.01 |
| B | xOneGo snap (the earlier Go line) | 1.25 | 1.15-1.25 (3 samples) |
| C | xOneRS snap | 0.57 | 0.49-0.61 |
| C | xOnePy snap | 0.18 | 0.16-0.18 |
Why does xOneC on Apothem show 13 GiB?
Because VmRSS counts file-backed pages too. Linux splits it into RssAnon (the process's own memory) and RssFile (pages of mapped files, such as a memory-mapped database). We read the split for six nodes at about 04:17 UTC:
| Host | Node | RssAnon (GiB) | RssFile (GiB) |
|---|---|---|---|
| C | xOneC snap, Apothem | 0.37 | 13.21 |
| B | reth-xdc full, Apothem | 3.16 | 8.56 |
| B | geth-XDC snap, Apothem | 5.96 | 0.03 |
| C | reth-xdc minimal, Apothem | 5.26 | 0.12 |
| C | erigon-xdc minimal, Apothem | 3.09 | 0.32 |
| B | xOneRS full, net2040 | 0.44 | 0.18 |
The xOneC Apothem node holds 0.37 GiB of its own memory. The other 13.2 GiB are database pages that the kernel can drop when another process needs the memory. The same is true for most of the reth-xdc full node's number. geth-XDC, by contrast, keeps almost all of its memory as its own heap and caches.
So VmRSS alone does not rank clients by the memory they need. For planning, read RssAnon, and leave room for the page cache that makes a memory-mapped database fast.
What does the table say about the xOne clients?
- On net2040, every xOne node used less than 0.65 GiB at 04:07 UTC, in all sync modes: full, archive, fast, minimal and snap.
- On Apothem, xOneRS snap used 0.57 GiB and xOnePy snap 0.18 GiB. xOneC snap's own memory was 0.37 GiB; the rest was file-backed.
- Several xOne nodes on host A moved a lot between samples (xOneRS archive 0.13 to 0.57, xOneC archive 0.09 to 0.66). Host A also runs builds, and the kernel takes back file-backed pages from processes under memory pressure. We did not record the split for those samples, so we cannot say which part moved.
- net2040 is much smaller than Apothem, so its numbers are not a forecast for Apothem or mainnet.
Was any reading corrected?
Yes. In the eighth sample our pid lookup matched the xOneGo node on host B to another process (the geth-XDC net2040 node), so the first value we recorded was that process's memory. We read the right process again (1,305,784 kB) and corrected the row. The lookup now accepts only an exact datadir match. We checked the three other pids that changed in that sample against their datadirs, and they were right.
Frequently asked questions
Which XDC client uses the least memory?
In this sample, the xOne nodes on net2040, at 0.08 to 0.62 GiB. On Apothem, xOnePy snap used 0.18 GiB. These are single-host readings at one time, not a benchmark.
Why is reth-xdc's memory so high on Apothem?
For the full node, most of it (8.56 of 11.7 GiB) is file-backed pages of its database. Its own memory was 3.16 GiB.
Should I size a server by VmRSS?
No. Use RssAnon for the client's own memory, then add memory for the page cache of the database.
How was memory measured?
VmRSS, RssAnon and RssFile from /proc/<pid>/status, read-only, with the pid found by the node's datadir.
Sources
- Fleet probe time series, 2026-11-14 19:20 UTC to 2026-11-15 04:07 UTC, 33 nodes on three hosts (read-only).
- Fleet snapshot of 2026-11-15, disk planning for xOne.
This article describes the source and evidence at its review date. Check the linked repository for current implementation and qualification status.
Explore the engineering evidenceEdit this page on GitHub opens the Markdown source (content/blog/xdc-client-memory-rss/index.md). GitHub may ask you to sign in. Report a correction opens a prefilled GitHub issue for this page.