Oddbean new post about | logout
▲ ▼
Jameson Lopp | 5 months ago (raw) | export | reply | flag +28 
 Today is a good day to publish some super nerdy research!
https://blog.lopp.net/effects-dbcache-size-bitcoin-node-sync-speed/
▲ ▼
Bitcoin Wizard 🧙🏻‍♂️ | 5 months ago (raw) | root | parent | reply | flag 
 interesting, good read.
▲ ▼
calle 👁️⚡👁️ | 5 months ago (raw) | root | parent | reply | flag +1 
 Love nerdy research, thank you
▲ ▼
Livestradamus | 5 months ago (raw) | root | parent | reply | flag 
 Love your work boss man
▲ ▼
andrewtoth | 5 months ago (raw) | root | parent | reply | flag 
 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
▲ ▼
andrewtoth | 5 months ago (raw) | root | parent | reply | flag 
 Setting higher dbcache benefits block validation time in addition to initial sync time. It should always be increased if there's enough free RAM.
▲ ▼
bogi | 5 months ago (raw) | root | parent | reply | flag 
 Is there/was there a hard cap in the code?  I thought I read on stack exchange dbcache is hard capped at 16gb.
▲ ▼
bogi | 5 months ago (raw) | root | parent | reply | flag 
 Nevermind... I read through the github link you posted and see there is a 16gb hard cap.
▲ ▼
bogi | 5 months ago (raw) | root | parent | reply | flag 
 Segwit was activated at block 481,824
▲ ▼
bogi | 5 months ago (raw) | root | parent | reply | flag 
 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.