Why does XMRig use fewer threads than my CPU has?
XMRig often uses fewer mining threads than your CPU offers because using every thread does not always mine Monero faster. Its automatic settings aim for useful performance, taking account of your CPU’s shared memory and hardware layout—not just the thread count shown in your system settings.
Your CPU’s thread count is not a mining target
A core is a physical processing unit inside your CPU. Many CPUs can run two logical threads on each core, so an 8-core processor may appear as 16 logical processors in your operating system.
Those two threads share parts of the same core. They do not give you twice the computing power.
A mining thread is one worker running mining calculations. XMRig does not necessarily create one worker for every logical processor. Monero uses RandomX, a mining algorithm—a set of computing rules—that favors CPUs but puts substantial demands on their memory resources.
Fewer workers can sometimes finish more calculations per second than a larger group competing for the same resources.
Shared cache is often the main limit
L3 cache is a small, fast memory area built into your CPU and shared by some or all of its cores. RandomX needs roughly 2 MB of L3 cache per mining thread for efficient operation.
For example, if your CPU has:
- 8 physical cores;
- 16 logical threads;
- 16 MB of L3 cache;
then around eight mining threads is a reasonable starting point. Running 16 workers would give each worker less room in that cache, potentially causing slower memory access rather than more useful work.
That is a rule of thumb, not an exact prediction. XMRig also considers other CPU details, including cache layout and available processors. Two CPUs with the same advertised thread count can therefore receive different automatic settings.
RandomX also uses a shared dataset of about 2,080 MB in fast mode. That is separate from the per-thread cache requirement. Adding more system RAM does not replace missing L3 cache.
Your configuration may also restrict threads
The automatic choice is not the only possible explanation. If the number looks unusually low, check:
- Your startup output: XMRig reports the CPU mining profile and how many threads it starts.
- Your configuration file: An explicitly saved CPU profile may specify fewer workers.
- The maximum-thread hint:
max-threads-hintguides automatic configuration. It is not a hard CPU-usage limit and does not override an existing explicit thread profile. - Processor restrictions: Your operating system, virtual machine, or container may expose only part of the CPU to XMRig.
A configuration copied from another computer may also be unsuitable for yours. Compare your active settings with a fresh configuration before assuming XMRig has detected your CPU incorrectly.
Test speed instead of chasing full CPU usage
The useful measurement is hashrate: how many mining calculations your computer completes each second.
Record your current steady hashrate, then test a slightly higher or lower thread count. Give each test several minutes under similar conditions. Compare:
- Hashrate, not just CPU usage.
- Power consumption and temperature.
- Fan noise and how responsive your computer feels.
If extra threads add heat but little or no hashrate, they are not helping. More heat can also make your CPU slow itself down to stay safe.
The bottom line
Fewer XMRig threads usually reflect resource limits, not wasted CPU capacity. Start with its automatic choice, check for configuration restrictions, and keep extra threads only when testing shows a worthwhile improvement.
