<p>The block index and chain state databases are LevelDB databases. LevelDB has its own caching and cache management. So 2 MiB is being allocated for the block index's LevelDB database cache, and 8 MiB is being allocated for the chain state's LevelDB database cache.</p>
<p>However Bitcoin Core does additional caching by itself, particularly for the UTXO set, which is stored in the chain state database. So Bitcoin Core is also allocating 441 MiB for itself to manage a cache of UTXO set entries.</p>
<p>The difference is that LevelDB will organize its cache differently from Bitcoin Core's in-memory UTXO set because LevelDB is a database system. So it is optimized for data handling and has a strategy that is generalized to all kinds of database uses. However Bitcoin Core knows what data it is putting into the database and so it can cache that more effectively. It caches the data before it needs to be serialized and written to the database. Because Bitcoin Core knows how the data will be used, it's caching through the in-memory UTXO set can be optimized for the actual use cases.</p>

CC BY-SA 4.0
2021-03-27T05:47:40.270Z
Thank you. Your answer is very helpful. So my understanding of the purpose of these caches is as follows (if I am wrong, please correct me):
When a node validates a transaction, for the UTXO used in the block, the node first performs a query in the 441MiB in-memory UTXO set. If it is not found, it needs to access the levelDB database in the disk. However, since levelDB also has an 8MiB cache, the node needs to query this 8MiB cache first. If it is still not found, go to the disk to search, and write the search result into the 8MiB cache instead of the 441MiB in-memory UTXO set.  Is it right？
GoneV
CC BY-SA 4.0
2021-03-27T17:53:48.353Z
@GoneV That's correct.
Ava Chow
CC BY-SA 4.0
2021-03-27T04:49:33.570Z
2021-03-27T04:49:33.570Z
Ava Chow
<p>In the debug.log file of BitCoin Core, the cache configuration is described as follows.</p>
<pre><code>Cache configuration:
  Using 2.0 MiB for block index database
  Using 8.0 MiB for chain state database
  Using 441.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
</code></pre>
<p>What is the 8MB cache space allocated for chainstate database here used for? What is the difference and connection between it and the in-memory UTXO set?</p>

<bitcoin-core><utxo-set><debugging><cache>
What do these memory configurations in debug.log of BitCoin Core represent?
GoneV
# What do these memory configurations in debug.log of BitCoin Core represent?

(Asked by: username_0 on 2021-03-27)

In the debug.log file of BitCoin Core, the cache configuration is described as follows.

```
Cache configuration:
  Using 2.0 MiB for block index database
  Using 8.0 MiB for chain state database
  Using 441.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)

```

What is the 8MB cache space allocated for chainstate database here used for? What is the difference and connection between it and the in-memory UTXO set?

**Tags:** bitcoin-core, utxo-set, debugging, cache


---

## 1 answers

### Answer by username_1 on 2021-03-27. Score: 3 | Accepted answer

The block index and chain state databases are LevelDB databases. LevelDB has its own caching and cache management. So 2 MiB is being allocated for the block index's LevelDB database cache, and 8 MiB is being allocated for the chain state's LevelDB database cache.

However Bitcoin Core does additional caching by itself, particularly for the UTXO set, which is stored in the chain state database. So Bitcoin Core is also allocating 441 MiB for itself to manage a cache of UTXO set entries.

The difference is that LevelDB will organize its cache differently from Bitcoin Core's in-memory UTXO set because LevelDB is a database system. So it is optimized for data handling and has a strategy that is generalized to all kinds of database uses. However Bitcoin Core knows what data it is putting into the database and so it can cache that more effectively. It caches the data before it needs to be serialized and written to the database. Because Bitcoin Core knows how the data will be used, it's caching through the in-memory UTXO set can be optimized for the actual use cases.

> **Comments:**
> **username_0**: Thank you. Your answer is very helpful. So my understanding of the purpose of these caches is as follows (if I am wrong, please correct me): When a node validates a transaction, for the UTXO used in the block, the node first performs a query in the 441MiB in-memory UTXO set. If it is not found, it needs to access the levelDB database in the disk. However, since levelDB also has an 8MiB cache, the node needs to query this 8MiB cache first. If it is still not found, go to the disk to search, and write the search result into the 8MiB cache instead of the 441MiB in-memory UTXO set.  Is it right？  
> **username_1**: @username_0 That's correct.  

---

