<p>According to BDB's <a href="https://docs.oracle.com/cd/E17275_01/html/programmer_reference/lock_max.html" rel="nofollow noreferrer">documentation</a>, there's actually 4 options controlling parameters in the locking subsystem:</p>
<ul>
<li><code>set_lk_max_locks</code></li>
<li><code>set_lk_max_lockers</code></li>
<li><code>set_lk_max_objects</code></li>
<li><code>set_lk_partitions</code></li>
</ul>
<p>From my understanding of the documentation, <code>max_lockers</code> and <code>partitions</code> are not really relevant for Bitcoin as there is not a whole lot of concurrent access to the database, which is what those parameters control.</p>
<p>However, if you look at the <code>db.log</code> file, there are entries when the failures occur that point to which parameters need to be increased.</p>
<p>On 0.5.0, the first error I ran into was <code>Lock table is out of available lock entries</code>. This indicates that <code>set_lk_max_locks</code> needs to be increased, and indeed, increasing it does get past the problem block.</p>
<p>The second error was <code>Lock table is out of available object entries</code>, and this I believe is the error you have run into here. This indicates that <code>set_lk_max_objects</code> needs to be increased. So this problem can be resolved by doing e.g. <code>set_lk_max_objects 1000000</code>, until you run out of locks or lock objects again, or some other problem comes up.</p>

CC BY-SA 4.0
2022-03-20T22:19:33.110Z
2022-03-20T22:25:11.970Z
2022-03-20T22:25:11.970Z
Ava Chow
<p>I compiled bitcoind using the same steps as <a href="https://bitcoin.stackexchange.com/questions/56439/bitcoind-0-5-3-stuck-at-block-274-011">last year</a>. In particular I set <code>DB_CONFIG</code>:</p>

<pre><code>set_lg_dir database
set_lk_max_locks 537000
</code></pre>

<p>Unfortunately once I hit block 364,670 (2015-07-10) I'm treated with:</p>

<pre><code>EXCEPTION: 11DbException
Db::put: Cannot allocate memory
bitcoin in ProcessMessage()
</code></pre>

<p>I tried raising <code>set_lk_max_locks</code> to 1000000 but that didn't help. This happens immediately when restarting the node, so it doensn't seem to be a RAM issue.</p>

<p>The <code>~/.bitcoin/database</code> looks rather large, assuming this is the equivalent of todays <code>~/.bitcoin/chainstate</code> and ``~/.bitcoin/blocks/index`.</p>

<pre><code>$ du -s ~/.bitcoin
92047404 # 88 GB
$ du -s ~/.bitcoin/database
42169668 # 41 GB
</code></pre>

<p>How can I get the synchronization to continue?</p>

CC BY-SA 4.0
2018-11-29T16:41:43.790Z
Hey Sjors, I sense a possible implicit question such as "What can I do to make the sync continue?", but could you actually add a phrase what you exactly are looking for in an answer to your post? :)
Murch
CC BY-SA 4.0
2018-11-30T13:04:20.157Z
I used the exact same wording as last year :-) Added "- what to do?" to the question. The goal is to get it unstuck.
Sjors Provoost
CC BY-SA 4.0
2020-06-19T02:39:09.230Z
Were you able to resolve this to continue the download?
LeanMan
CC BY-SA 4.0
2022-03-23T13:54:00.213Z
@LeanMan no, but I believe Andrew Chow is trying at the moment (see his answer below).
Sjors Provoost
<bitcoin-core><synchronization>
Bitcoind 0.5.3 stuck at block 364,670 - what to do?
Sjors Provoost
# Bitcoind 0.5.3 stuck at block 364,670 - what to do?

(Asked by: username_0 on 2018-11-29)

I compiled bitcoind using the same steps as last year. In particular I set DB_CONFIG:
set_lg_dir database
set_lk_max_locks 537000

Unfortunately once I hit block 364,670 (2015-07-10) I'm treated with:
EXCEPTION: 11DbException
Db::put: Cannot allocate memory
bitcoin in ProcessMessage()

I tried raising set_lk_max_locks to 1000000 but that didn't help. This happens immediately when restarting the node, so it doensn't seem to be a RAM issue.
The ~/.bitcoin/database looks rather large, assuming this is the equivalent of todays ~/.bitcoin/chainstate and ``~/.bitcoin/blocks/index`.
$ du -s ~/.bitcoin
92047404 # 88 GB
$ du -s ~/.bitcoin/database
42169668 # 41 GB

How can I get the synchronization to continue?

**Tags:** bitcoin-core, synchronization

> **Comments:**
> **username_1**: Hey Sjors, I sense a possible implicit question such as "What can I do to make the sync continue?", but could you actually add a phrase what you exactly are looking for in an answer to your post? :)  
> **username_0**: I used the exact same wording as last year :-) Added "- what to do?" to the question. The goal is to get it unstuck.  
> **username_2**: Were you able to resolve this to continue the download?  
> **username_0**: @username_2 no, but I believe Andrew Chow is trying at the moment (see his answer below).  

---

## 1 answers

### Answer by username_3 on 2022-03-20. Score: 4

According to BDB's [documentation](https://docs.oracle.com/cd/E17275_01/html/programmer_reference/lock_max.html), there's actually 4 options controlling parameters in the locking subsystem:

* `set_lk_max_locks`
* `set_lk_max_lockers`
* `set_lk_max_objects`
* `set_lk_partitions`

From my understanding of the documentation, `max_lockers` and `partitions` are not really relevant for Bitcoin as there is not a whole lot of concurrent access to the database, which is what those parameters control.

However, if you look at the `db.log` file, there are entries when the failures occur that point to which parameters need to be increased.

On 0.5.0, the first error I ran into was `Lock table is out of available lock entries`. This indicates that `set_lk_max_locks` needs to be increased, and indeed, increasing it does get past the problem block.

The second error was `Lock table is out of available object entries`, and this I believe is the error you have run into here. This indicates that `set_lk_max_objects` needs to be increased. So this problem can be resolved by doing e.g. `set_lk_max_objects 1000000`, until you run out of locks or lock objects again, or some other problem comes up.


---

