How often should cache flushes happen during synchronization with this setup?

[takuma sato]

So im doing a backup of a full node from one drive into another. I installed Bitcoin Core 29.4 and copied the blocks folder. I like to create a brand new chainstate folder so I left it verifying all the blocks. It was fast until around 64%, block heights around august 2023 or so, which I reckon started going slower, but when I came back it was stuck with the following message:

Code:

2026-09-01T18:25:15Z Cache size (17469837200) exceeds total space (17469383424)
2026-09-01T18:25:16Z [warning] Flushing large (16 GiB) UTXO set to disk, it may take several minutes

My bitcoin.conf settings:

Code:

dbcache=16384
par=16

It's a 32GB system with an AMD CPU 32 threads and im using an 8TB HDD.

Does anyone know how often should this happen? Because after 64%, it took around an hour, and then at around 74%, it's happening again. So is it going to take an hour every 10% stuck with that message?

Btw, I would like to request to devs a sort of progress % being prompted by bitcoind so I can see something on the debug.log instead of the "[warning] Flushing large (16 GiB) UTXO set to disk, it may take several minutes" message as some people may run out of patience and close Bitcoin Core in this state which is probably not a good idea. There is no indication of anything going on on the GUI as well.

[BitMaxz]

It seems that Bitcoin Core paused or hang because it exceeds the total space of "17469383424" it's beyond your setup of "dbcache=16384".

If you kill the process, the chainstate will likely be corrupted; however, if you do not change this setting, we cannot guarantee that the process will complete.
So, if you want to fix this case for me, you can try killing the process and remove this dbcache then try to run it again.

Or I think increase the dbcache just don't put it to maximum. You might try increasing it above between 20000 to 25000 something.

[nc50lc]

It's a 32GB system with an AMD CPU 32 threads and im using an 8TB HDD.

This is expected because it's flushing large amount of data to an HDD.
If it's an SSD, it would've been faster.

Changing your database cache size will just make that quite faster but in shorter intervals.
Do that if that's what you prefer but I'd personally just let it finish reindex.

[LoyceV]

Does anyone know how often should this happen? Because after 64%, it took around an hour, and then at around 74%, it's happening again. So is it going to take an hour every 10% stuck with that message?

As far as I know, cache is only flushed when it's full. So with sufficient RAM, it would only be written to disk when you shut down Bitcoin Core. That's one of the reasons I reduce dbcache after the IBD is done.
Based on nc50lc's post, this wasn't correct. I've just never noticed it without shutting down.

[ABCbits]

My bitcoin.conf settings:

Code:

dbcache=16384
par=16

It's a 32GB system with an AMD CPU 32 threads and im using an 8TB HDD.

Does anyone know how often should this happen? Because after 64%, it took around an hour, and then at around 74%, it's happening again. So is it going to take an hour every 10% stuck with that message?

Have you consider to increase the dbcache to eliminate or reduce the flush frequency? Unless you run one or more other RAM intensive apps, there should be lots of free/unused RAM.

P.S. I expect most member here wouldn't estimate the flush frequency, without also knowing usually size of UTXO after deserialized and cache behavior.

[nc50lc]

Unfortunately, even with enough dbcache, Core will still flush its database to disk approximately every hour (50~70min).
So that in case of a crash where it lost all the data that's only kept in memory, the version about an hour ago is already flashed to disk.

Ref:

• github.com/bitcoin/bitcoin/blob/dc0395c5858a1d55239b82a834e5075cf2069219/src/validation.cpp#L94-L99
• github.com/bitcoin/bitcoin/blob/dc0395c5858a1d55239b82a834e5075cf2069219/src/validation.cpp#L2764-L2765

Its speed can't be improved since it's being written to an HDD.