How DBcache Size Affects Bitcoin Node Sync Speed

So, Jameson Lopp ran another test, this time focusing on DBcache to figure out the best settings for syncing a Bitcoin node as fast as possible. He also shared some related discussions and resources like data sheets. From what I gather, if you're planning to run a Bitcoin Core full node and sync it, you’ll need some pretty top-notch hardware, like an SSD and lots of RAM. Plus, tweaking the DBcache setting is crucial to avoid crashes and reindexing problems. Oh, and Lopp has a 2023 performance test article for Bitcoin nodes too.

His finding is interesting. Aside from stated theory, i was expecting bigger difference between default cache and 28GB cache. I wonder about the result if he used cheap SATA SSD or HDD instead.

"Node Crash" isn't caused by the higher database cache size, it's to minimize the chance of corruption of the UTXO set if the user is expecting frequent force close. In general use-case, that isn't even a concern and most would've preferred faster sync speed. Plus they use "probably" so the conclusion regarding higher dbcache could potentially cause higher chance of corruption on abrupt shutdowns may be debatable. Because a low dbcache setting that causes frequent flushing of chainstate to disk may also be a factor to consider specially on slow drives.

A Raspberry Pi doesn't have 28 GB RAM. Low end hardware forces you to use less DBcache. Thats because the system still has 32 GB memory. He should perform the same test with more aggressive file system caching.

I highly doubt that more aggressive filesystem caching, or even having the chainstate be on ramdisk, would result in a meaningful time difference. In reading and writing data to disk, Bitcoin Core has to do so many more things than if it simply skipped it because it had a large dbcache. These include leveldb needing to figure out which file to read, leveldb's own decompression of the data in that file, Bitcoin Core having to decompress its own compressed representations of the UTXO, allocating memory for the UTXO, etc. These are all things that happen independently of whether the file is read from fast or slow storage. These things are all skipped when there's a large dbcache and that saves CPU time.

Not me though. Performance here follows the law of diminishing returns. Once you have so much memory allocated to the dbcache, even the larger blocks just fit inside it along with all their transactions and immediate parent TXOs, so the dbcache doesn't get fully utilized as a result. That's why the performance improvement seems to stagger between the orange and green lines.