How much memory does RandomX need?

RandomX uses three pieces of memory, and the figure people quote — about 2 GB — is the biggest of them. All three sizes are set in the specification and are the same in RandomX v1 and v2.

The three pieces

The dataset: 2080 MiB, shared. A read-only block of 2,147,483,648 bytes plus 33,554,368 bytes of extra, built once from the cache and read by every mining thread. It is rebuilt when the key changes — on Monero, every 2048 blocks, about 2.8 days. Only fast mode, the mode for mining, has one.

The cache: 256 MiB, shared. 262,144 blocks of 1 KiB, made from the key with Argon2d. The dataset is built from it. In light mode there is no dataset and each item is worked out from the cache when it is needed: the same hash, much more slowly. That is the mode for verifying blocks, not for mining them.

The scratchpad: 2 MiB per thread. Every mining thread has its own, split into levels of 16 KiB, 256 KiB and 2 MiB that are meant to sit in the processor's L1, L2 and L3 caches. This is the figure behind the README's requirement of 2 MiB of L3 cache per mining thread, and it is why miners such as XMRig choose a thread count from the size of the L3 cache: on a processor with 16 MiB of L3, eight scratchpads fill it, and a ninth has nowhere to go but main memory.

What a machine needs

For mining, the README asks for at least 2.5 GiB of free RAM per NUMA node. That covers the 2080 MiB dataset, the 256 MiB cache it is built from and a 2 MiB scratchpad per thread, with some room to spare. "Per NUMA node" matters on servers with more than one processor socket: the dataset is best kept in the memory next to the cores that read it, so a two-socket machine wants that much free on each side.

Free means free. A computer with 4 GiB of RAM and a desktop running has rarely got 2.5 GiB to give, and a dataset that is pushed out to swap makes every hash wait on the disk. The README notes that the requirement of more than 2 GiB rules out many low-end machines, such as the IoT devices that make up large botnets — and makes web mining infeasible.

Bandwidth, not only size

Every loop of every program reads a 64-byte line of the dataset at an address that cannot be known in advance, so a processor spends much of each hash waiting on memory. The README's rule of thumb is about 1500 to 2000 hashes a second per channel of DDR3 and 4000 to 6000 per channel of DDR4, depending on frequency and timings. A fast processor with one memory module installed is held to one channel's worth.

Huge pages

The README lists support for large memory pages among RandomX's requirements. With ordinary 4 KiB pages, a 2080 MiB dataset spans more than half a million pages, and almost every random read also misses the processor's table of page addresses. Huge pages of 2 MiB cut that to about a thousand. On Linux they have to be reserved; P2Pool's own instructions reserve 3072 of them, 6 GiB, because monerod, P2Pool and XMRig each want some. XMRig can also put the dataset in 1 GiB pages, on Linux only.

Not every system has them. On a Mac with Apple Silicon we found no 2 MiB pages to be had at all — the Apple Silicon guide has what we measured.