fix: cap indexed-node block-tree dbcache so adaptive dbcache feeds the UTXO set
With -addressindex/-spentindex, nBlockTreeDBCache was set to 3/4 of nTotalCache. That rule was sized for the old fixed 512 MiB dbcache default (~384 MiB), but adaptive dbcache now makes nTotalCache multi-GB, so on indexed pool/explorer nodes ~3/4 of several GB was diverted to the block-index LevelDB read cache -- far more than it can use -- while starving the in-memory UTXO set that actually speeds IBD, and that chunk is not shrinkable by the memory-pressure controller. Measured on an 8 GiB box with -addressindex: 4420 MiB block-index cache + 1097 MiB UTXO set, vs 3859 MiB UTXO on a plain node. Cap the index cache at 1 GiB (ample for the index read cache; tunable) so the adaptive budget flows to the coins cache. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -2002,8 +2002,14 @@ bool AppInit2(boost::thread_group& threadGroup, CScheduler& scheduler)
|
||||
int64_t nBlockTreeDBCache = nTotalCache / 8;
|
||||
|
||||
if (GetBoolArg("-addressindex", DEFAULT_ADDRESSINDEX) || GetBoolArg("-spentindex", DEFAULT_SPENTINDEX)) {
|
||||
// enable 3/4 of the cache if addressindex and/or spentindex is enabled
|
||||
// Give indexed (address/spent-index) nodes a larger index LevelDB read cache, but CAP it.
|
||||
// With adaptive dbcache, nTotalCache is now multi-GB, so 3/4 of it is several GB -- far more
|
||||
// than the index cache can use, while starving the in-memory UTXO set that actually speeds
|
||||
// IBD (and this chunk is not shrinkable by the memory-pressure controller, which only adjusts
|
||||
// the coins cache). Cap at 1 GiB so the adaptive budget flows to the coins cache. Tunable.
|
||||
nBlockTreeDBCache = nTotalCache * 3 / 4;
|
||||
if (nBlockTreeDBCache > ((int64_t)1024 << 20))
|
||||
nBlockTreeDBCache = ((int64_t)1024 << 20);
|
||||
} else {
|
||||
if (nBlockTreeDBCache > (1 << 21) && !GetBoolArg("-txindex", false)) {
|
||||
nBlockTreeDBCache = (1 << 21); // block tree db cache shouldn't be larger than 2 MiB
|
||||
|
||||
Reference in New Issue
Block a user