user4948: 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?

user48884: According to BDB's documentation, 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.

4948: <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>
 48884: <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>
