<p>After a point, there's no reason to increase memory usage further.</p>
<ul>
<li><p><code>dbcache</code> is useful up until the point where you have the entire UTXO in memory (4GB+ in 2021), and then increasing it further does not a lot other than increasing the time to shutdown the node safely (up to many minutes on a slow disk)</p>
</li>
<li><p><code>maxmempool</code> will increase performance by allowing more transactions (and their validity) to be ready for their inclusion in a block, but only up to the point where you are including all of the possible transactions that miners are likely to include.</p>
</li>
<li><p><code>blockreconstructionextratxn</code> will allow the node to store more transactions which are not in the mempool, but are still valid. This increases the efficiency of compact block transmission as sometimes transactions will be evicted from your mempool but may be in other people's. This setting notably is in number of transactions, not megabytes.</p>
</li>
<li><p><code>maxorphantx</code> increases transaction relay efficiency by keeping copies of transactions which could not be connected to a parent (and therefor can't be validated!), but might become valid in the future by the arrival of their parent. This setting is also in number of transactions, not megabytes.</p>
</li>
</ul>
<p>These are about as far as you can go just by tweaking the settings in <code>bitcoin.conf</code>.</p>
<hr />
<p>A &quot;hot rod&quot;, &quot;no cost considered&quot; Bitcoin Core node would look a bit different.</p>
<p>The entire UTXO would be stored in a ramdisk (to prevent a cold <code>dbcache</code> ever occurring), with the obvious cost that unexpected shutdowns would result in a complete loss of synchronization state. As many cores as possible would be in use, the node would make connections to other nodes owned by the operator for maximum efficiency, and those nodes would be tuned to have as many high quality peers as possible.</p>
<p>You can go a long way towards making extremely performant nodes with not an unreasonable financial outlay if there's a reason to do so, it's just a matter of optimizing the right parameters and limiting bottlenecks that are normally caused by the network being optimized for stability and correctness.</p>

CC BY-SA 4.0
2021-02-20T05:54:59.627Z
_"After a point, there's no reason to increase memory usage further"_
That's precisely what my question is about. What exactly is that point?
intelfx
CC BY-SA 4.0
2021-02-20T05:56:58.990Z
As written in the answer, the limit for `dbcache` is the size of the UTXO database, which is around 4GB today (depending how it is stored). The other ones are as far as I'm aware are not documented enough to be able to state sensible limits.
Claris
CC BY-SA 4.0
2021-09-02T19:17:11.987Z
"blockreconstructionextratxn will allow the node to store more transactions which are not in the mempool, but are still valid" - why are they not in the mempool?
Rebroad
CC BY-SA 4.0
2021-09-02T19:18:09.967Z
They conflict with another transaction in the mempool, but this does not make them invalid.
Claris
CC BY-SA 4.0
2021-02-20T05:51:39.887Z
2021-02-20T05:58:44.580Z
2021-02-20T05:58:44.580Z
Claris
<p>In contrast to this question about <a href="https://bitcoin.stackexchange.com/questions/50580/how-to-run-bitcoind-in-a-low-memory-environment">running Bitcoind in a low-memory environment</a>, I have an opposite use-case.</p>
<p>I want to run a bitcoind full node (no wallet) on a Linux server with lots of memory but not particularly fast disks. What are the maximum useful memory constraints (<code>dbcache=</code>, <code>maxmempool=</code> and total amount of page cache) that you can give to bitcoind to maximize its performance? That is, at which point does giving more memory to bitcoind start yielding diminished returns?</p>

<bitcoin-core><bitcoind><performance><memory><cache>
What are the maximum useful memory limits for a Bitcoind full node?
intelfx
# What are the maximum useful memory limits for a Bitcoind full node?

(Asked by: username_0 on 2021-02-20)

In contrast to this question about [running Bitcoind in a low-memory environment](https://bitcoin.stackexchange.com/questions/50580/how-to-run-bitcoind-in-a-low-memory-environment), I have an opposite use-case.

I want to run a bitcoind full node (no wallet) on a Linux server with lots of memory but not particularly fast disks. What are the maximum useful memory constraints (`dbcache=`, `maxmempool=` and total amount of page cache) that you can give to bitcoind to maximize its performance? That is, at which point does giving more memory to bitcoind start yielding diminished returns?

**Tags:** bitcoin-core, bitcoind, performance, memory, cache


---

## 1 answers

### Answer by username_1 on 2021-02-20. Score: 3 | Accepted answer

After a point, there's no reason to increase memory usage further.

* `dbcache` is useful up until the point where you have the entire UTXO in memory (4GB+ in 2021), and then increasing it further does not a lot other than increasing the time to shutdown the node safely (up to many minutes on a slow disk)
* `maxmempool` will increase performance by allowing more transactions (and their validity) to be ready for their inclusion in a block, but only up to the point where you are including all of the possible transactions that miners are likely to include.
* `blockreconstructionextratxn` will allow the node to store more transactions which are not in the mempool, but are still valid. This increases the efficiency of compact block transmission as sometimes transactions will be evicted from your mempool but may be in other people's. This setting notably is in number of transactions, not megabytes.
* `maxorphantx` increases transaction relay efficiency by keeping copies of transactions which could not be connected to a parent (and therefor can't be validated!), but might become valid in the future by the arrival of their parent. This setting is also in number of transactions, not megabytes.

These are about as far as you can go just by tweaking the settings in `bitcoin.conf`.

---

A "hot rod", "no cost considered" Bitcoin Core node would look a bit different.

The entire UTXO would be stored in a ramdisk (to prevent a cold `dbcache` ever occurring), with the obvious cost that unexpected shutdowns would result in a complete loss of synchronization state. As many cores as possible would be in use, the node would make connections to other nodes owned by the operator for maximum efficiency, and those nodes would be tuned to have as many high quality peers as possible.

You can go a long way towards making extremely performant nodes with not an unreasonable financial outlay if there's a reason to do so, it's just a matter of optimizing the right parameters and limiting bottlenecks that are normally caused by the network being optimized for stability and correctness.

> **Comments:**
> **username_0**: _"After a point, there's no reason to increase memory usage further"_ That's precisely what my question is about. What exactly is that point?  
> **username_1**: As written in the answer, the limit for `dbcache` is the size of the UTXO database, which is around 4GB today (depending how it is stored). The other ones are as far as I'm aware are not documented enough to be able to state sensible limits.  
> **username_2**: "blockreconstructionextratxn will allow the node to store more transactions which are not in the mempool, but are still valid" - why are they not in the mempool?  
> **username_1**: They conflict with another transaction in the mempool, but this does not make them invalid.  

---

