Avatar
Jameson Lopp 1y ago

Today is a good day to publish some super nerdy research!

https://blog.lopp.net/effects-dbcache-size-bitcoin-node-sync-speed/

Reply to this note

Please Login to reply.

Discussion

Avatar
Bitcoin Wizard 🧙🏻‍♂️ 1y ago

interesting, good read.

Avatar
calle 1y ago

Love nerdy research, thank you

Avatar
Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 1y ago

Love your work boss man

Avatar
andrewtoth 1y ago

The dbcache *is* a read cache, and this misconception has kept block validation times longer than they need to be. This problem will be fixed in v28. https://github.com/bitcoin/bitcoin/pull/28233

Avatar
andrewtoth 1y ago

Setting higher dbcache benefits block validation time in addition to initial sync time. It should always be increased if there's enough free RAM.

5f
Bogi 1y ago

Is there/was there a hard cap in the code? I thought I read on stack exchange dbcache is hard capped at 16gb.

5f
Bogi 1y ago

Nevermind... I read through the github link you posted and see there is a 16gb hard cap.

5f
Bogi 1y ago

Segwit was activated at block 481,824

5f
Bogi 1y ago

Are you using a custom Bitcoin Core node? Because dbcache is hard capped at 16gb currently. Though if you read that github link andrewtoth posted you'll see they are trying to increase it maybe by next release.