XMRig Config Guide: Huge Pages, MSR Mod and Thread Tuning

The first twenty lines XMRig prints show if the miner is running at full hashrate. Two phrases matter: huge pages 100% and preset have been set successfully. If both are there, the big gains are already yours. XMRig’s own docs credit huge pages with up to 50% more RandomX hashrate, and the MSR mod adds between 6% and 28% in the examples the docs link to.

This guide starts from that log, because most low-hashrate problems announce themselves in one of its lines.

How do you read the XMRig startup log?

The XMRig startup log reports huge-page permission, the MSR mod result and the thread count, in that order. Start the miner once with elevated rights (sudo ./xmrig on Linux, “Run as administrator” on Windows) and look for these lines. The text is quoted from XMRig’s source.

Which XMRig version should you run?

Run XMRig 6.26.0, the current release as of 11 November 2026. Get it from xmrig.com/download or the GitHub releases page and nowhere else.

The version matters for more than speed. Monero’s next hard fork switches to RandomX v2, and a miner without v2 support will produce invalid hashes from the fork height. No date is set. Our FCMP++ status page tracks it.

Warning: “Optimized” XMRig builds from video descriptions and forum attachments are a common way to lose hashrate to someone else’s wallet, or worse. Check the SHA256 sum against the SHA256SUMS file on the release page before the first run.

A config.json to start from

XMRig reads config.json from its own folder, or from the path given with -c. The wizard generates one. This minimal version mines to a local P2Pool node:

{
  "autosave": true,
  "cpu": {
    "enabled": true,
    "huge-pages": true,
    "huge-pages-jit": false,
    "priority": null,
    "yield": true,
    "max-threads-hint": 100
  },
  "randomx": {
    "mode": "auto",
    "1gb-pages": false,
    "wrmsr": true,
    "rdmsr": true,
    "numa": true
  },
  "pools": [
    {
      "url": "127.0.0.1:3333",
      "user": "x",
      "keepalive": true,
      "tls": false
    }
  ]
}

With P2Pool, user is ignored for payouts because P2Pool pays the wallet it was started with. Our P2Pool setup guide covers that side. For a centralized pool, put the pool’s stratum address in url and your Monero address in user, and set "tls": true on the pool’s TLS port so the stratum traffic isn’t readable on the wire. tls-fingerprint pins the pool’s certificate.

The options people change, from the CPU config docs:

• yield (default true). Set false on a dedicated rig for slightly more hashrate at the cost of system responsiveness.
• priority (default null). 1 is lowest and 5 highest. Anything above 2 can make a desktop unusable.
• max-threads-hint (default 100). A hint for auto-config, not a CPU usage cap. To mine on about half the CPU of a PC you work on, set it to 50 and delete the generated "rx" array so XMRig rebuilds it. The hint does nothing once that array exists.
• huge-pages-jit (default false). A very small gain on Ryzen with hashrate that varies between launches. Leave it off unless you test it.

How do you get huge pages to 100%?

Give XMRig the right to allocate huge pages and make sure enough are free. RandomX reads a 2,080 MB dataset at random, and with ordinary 4 KB pages the CPU wastes time translating addresses. The huge pages docs quote a typical 20 to 30% gain and up to 50% for RandomX.

Linux. Running as root is enough. XMRig reserves the pages it needs. Without root, reserve 1,280 pages per NUMA node (2,560 MB that other programs can no longer use):

sudo sysctl -w vm.nr_hugepages=1280
sudo bash -c "echo vm.nr_hugepages=1280 >> /etc/sysctl.conf"

The first line lasts until reboot and the second makes it permanent. On a box that also runs monerod and P2Pool, use 3,072, the figure in the P2Pool README.

Windows. XMRig needs the “Lock pages in memory” privilege. Run it as Administrator once, then reboot. On Windows 10 and 11 huge pages work without admin rights from then on. Windows can’t reserve huge pages ahead of time, so after days of uptime the allocation can come in under 100%. Rebooting and starting the miner before anything else fixes that. XMRig’s guide also warns that 4 GB of RAM may not be enough on Windows.

1 GB pages, Linux only. Set "1gb-pages": true in the randomx block for another 1 to 3%, at a cost of 3 GB reserved per NUMA node. Root handles it automatically. Otherwise run sudo ./scripts/enable_1gb_pages.sh from the XMRig source tree. Worth doing on a dedicated Linux rig with RAM to spare, pointless on an 8 GB desktop.

What does the MSR mod do, and why does it fail?

The MSR mod reconfigures the CPU’s hardware prefetchers, which guess wrong on RandomX’s random memory reads and waste memory bandwidth doing it. Some of those prefetchers can’t be switched off in the BIOS, so XMRig writes the model-specific registers directly.

It works on Intel from Nehalem onward and on every Zen-based AMD chip. The MSR docs link two measured examples: a Ryzen 7 3700X on Windows going from 9,100 to 9,670 H/s (6%), and an i7-7700K going from 537 to 687 H/s on one thread (28%). Expect the gain on your chip to fall somewhere in that range.

When the log says FAILED TO APPLY MSR MOD, the cause is one of four things:

1. No elevated rights. The mod needs root or Administrator every time, unlike huge pages.
2. Linux msr module missing. XMRig tries modprobe msr allow_writes=on itself. In a container or on a kernel built without the module it can’t.
3. Secure Boot. On some systems it blocks MSR writes. The docs point to GitHub issue #1891. Disabling Secure Boot in firmware setup is the fix, and it is a security trade-off on a PC you use for other things.
4. Windows driver blocked or missing. XMRig uses the signed WinRing0 driver that ships in the release archive.

If you won’t run the miner as root on Linux, apply the mod separately after each boot with sudo ./scripts/randomx_boost.sh from the source tree, then run XMRig as a normal user. The script covers Zen 1 through Zen 5 and Intel.

Note: Root or Administrator gives XMRig full control of the machine. On a dedicated mining box that is normal practice. On a PC that holds your wallet, prefer the Linux script route, or keep the wallet elsewhere.

How many threads should XMRig use?

XMRig should use one thread for every 2 MB of L3 cache, which is what auto-config does. Each RandomX thread needs 256 KB of L2 and 2 MB of L3. A Ryzen 5 5600X has 32 MB of L3 and 12 threads, so all 12 run. An i9-14900K has 36 MB and 32 threads, so 18 run and the task manager shows the CPU “only” 56% busy. That is correct behaviour.

Forcing the idle threads on makes them fight over cache, and total hashrate falls. To test for yourself, note the 15-minute average with the auto-generated "rx" array, remove or add one entry, and compare. The array lists one CPU core index per thread, such as [0, 2, 4, 6].

Per-CPU figures and L3 sizes are in our RandomX CPU comparison.

Memory channels and NUMA

RandomX hashrate is capped by memory channels at about 4,000 to 6,000 H/s per DDR4 channel and 1,500 to 2,000 H/s per DDR3 channel, according to XMRig’s optimization guide. A 16-core Ryzen on one DIMM is limited to a single channel’s worth. Two DIMMs in the correct slots (usually A2 and B2, check the board manual) is the cheapest hashrate fix there is.

On multi-socket servers keep "numa": true. XMRig then builds one 2,080 MB dataset per NUMA node. Turning it off saves memory and, in the docs’ words, will “reduce hashrate significantly”.

Low hashrate: what to check, in order

1. huge pages below 100% in the log. Fix this first. It is the largest loss.
2. MSR line missing or failed.
3. One memory channel populated.
4. Temperature. Laptops and small cases throttle within minutes. If the 10-second hashrate starts high and sags, heat is the cause.
5. Light mode. If RandomX can’t allocate the dataset it falls back to a mode that needs 256 MB and is far slower. Close other programs or add RAM.
6. Board power limits set below the CPU’s rating.
7. Expectations. Figures on xmrig.com/benchmark are the best submission per CPU from tuned systems.

Once the log is clean, hashrate is as good as the hardware allows, and the remaining question is whether the watts are worth it. The profitability post and the mining calculator on the tools page answer that with your own numbers.

Three settings are worth knowing beyond tuning. The http block exposes hashrate over a local API for monitoring. Bind it to 127.0.0.1 or set an access-token, and never expose it to the internet. "background": true runs XMRig without a console window. XMRig’s OpenCL and CUDA backends can run RandomX too. Leave them off for Monero, because RandomX on a GPU returns very little per watt.