<p>You are right UTXO set is stored on disk on .bitcoin/chainstate directory using leveldb. It is stored in compressed state and the current size is around 1.5GB</p>

<p>To speed up access bitcoind uses an in memory cache which can be configured using -dbcache option.  </p>

<blockquote>
  <p>So, I assume the chainstate-db is stored on disk, but accessed
  multiple times per second to check transaction inputs. What amount of
  memory usage does this induce on a node?</p>
</blockquote>

<p>Accessing the leveldb database itself is like accessing any other nosql database. You basically lookup the key which is the utxo and get a value as output which you need to deserialize and store in a memory variable</p>

CC BY-SA 3.0
2016-04-27T08:29:21.493Z
So, essentially, it'll fill `-dbcache` amount of memory long term with some spikes whenever I access the db?
Murch
CC BY-SA 3.0
2016-04-28T05:45:52.250Z
Yes, there is also memory taken by mempool which can be controlled by maxmempoolsize.  Also there are some minor caches maintained by leveldb and other parts of code which I am not aware of. These are memory cache options documented for configuration in bitcoin
dark knight
CC BY-SA 3.0
2016-04-27T06:20:05.920Z
2016-04-27T06:20:05.920Z
dark knight
<p>Whenever a transaction is received by a node, the node verifies its validity. To that end, it checks for each transaction input whether that input is part of the UTXO set. It is my understanding that the UTXO set is stored in the chainstate database, which is held in a <code>LevelDB</code> structure.</p>

<p>I previously thought that he UTXO set was kept available in memory, but since I've learned that it is currently <a href="http://statoshi.info/dashboard/db/unspent-transaction-output-set" rel="nofollow">about 1.2GiB in size</a> that seems unlikely.</p>

<p>So, I assume the chainstate-db is stored on disk, but accessed multiple times per second to check transaction inputs. What amount of memory usage does this induce on a node?</p>

CC BY-SA 3.0
2016-04-26T10:10:34.277Z
It needs to be stored on disk to preserve it when closing and then opening the application. However most (or on systems with enough memory: all) of it is also in RAM. Every time it needs to scan through the UTXO set, it will load the used chunks into memory and keep them there as long as possible. I imagine after a few scans most of it will be in memory. If it does not fit in memory, it will quickly increase the disk I/O and slow everything down.
Jannes
<transaction-verification><utxo><leveldb><memory><transaction-input>
What is the memory usage for checking transaction inputs?
Murch
# What is the memory usage for checking transaction inputs?

(Asked by: username_0 on 2016-04-26)

Whenever a transaction is received by a node, the node verifies its validity. To that end, it checks for each transaction input whether that input is part of the UTXO set. It is my understanding that the UTXO set is stored in the chainstate database, which is held in a `LevelDB` structure.

I previously thought that he UTXO set was kept available in memory, but since I've learned that it is currently [about 1.2GiB in size](http://statoshi.info/dashboard/db/unspent-transaction-output-set) that seems unlikely.

So, I assume the chainstate-db is stored on disk, but accessed multiple times per second to check transaction inputs. What amount of memory usage does this induce on a node?

**Tags:** transaction-verification, utxo, leveldb, memory, transaction-input

> **Comments:**
> **username_1**: It needs to be stored on disk to preserve it when closing and then opening the application. However most (or on systems with enough memory: all) of it is also in RAM. Every time it needs to scan through the UTXO set, it will load the used chunks into memory and keep them there as long as possible. I imagine after a few scans most of it will be in memory. If it does not fit in memory, it will quickly increase the disk I/O and slow everything down.  

---

## 1 answers

### Answer by username_2 on 2016-04-27. Score: 1 | Accepted answer

You are right UTXO set is stored on disk on .bitcoin/chainstate directory using leveldb. It is stored in compressed state and the current size is around 1.5GB

To speed up access bitcoind uses an in memory cache which can be configured using -dbcache option.

> So, I assume the chainstate-db is stored on disk, but accessed
> multiple times per second to check transaction inputs. What amount of
> memory usage does this induce on a node?

Accessing the leveldb database itself is like accessing any other nosql database. You basically lookup the key which is the utxo and get a value as output which you need to deserialize and store in a memory variable

> **Comments:**
> **username_0**: So, essentially, it'll fill `-dbcache` amount of memory long term with some spikes whenever I access the db?  
> **username_2**: Yes, there is also memory taken by mempool which can be controlled by maxmempoolsize.  Also there are some minor caches maintained by leveldb and other parts of code which I am not aware of. These are memory cache options documented for configuration in bitcoin  

---

