Bump dbcache to 1 GiB

andrewtoth commented at 2:25 pm on February 27, 2026: contributor

Alternative to #34641

This increases the default dbcache value from 450MiB to 1024MiB if:

dbcache is unset
The system is 64 bit
At least 4GiB of RAM is detected

Otherwise fallback to previous 450MiB default.

This should be simple enough to get into v31. The bump to 1GiB shows significant performance increases in #34641. It also alleviates concerns of too high default for steady state, and of lowering the current dbcache for systems with less RAM.

This change only changes bitcoind behavior, while kernel still defaults to 450 MiB.

DrahtBot commented at 2:26 pm on February 27, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	sipa, ajtowns, kevkevinpal, svanstaa, achow101
Concept ACK	yancyribbens, darosior

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#34641 (node: scale default -dbcache with system RAM by l0rinc)
#34435 (refactor: use _MiB/_GiB consistently for byte conversions by l0rinc)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

andrewtoth force-pushed on Feb 27, 2026

DrahtBot added the label CI failed on Feb 27, 2026

DrahtBot commented at 2:35 pm on February 27, 2026: contributor

🚧 At least one of the CI tasks failed. Task 32 bit ARM: https://github.com/bitcoin/bitcoin/actions/runs/22490076628/job/65149651058 LLM reason (✨ experimental): C++ compile error: constexpr evaluation fails due to throwing in a constexpr context (MiB value too large for size_t).

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

DrahtBot removed the label CI failed on Feb 27, 2026

in src/node/caches.cpp:40 in 6b0210ebe2

36@@ -37,6 +37,11 @@ size_t CalculateDbCacheBytes(const ArgsManager& args)
37         constexpr auto max_db_cache{sizeof(void*) == 4 ? MAX_32BIT_DBCACHE : std::numeric_limits<size_t>::max()};
38         return std::max<size_t>(MIN_DB_CACHE, std::min<uint64_t>(db_cache_bytes, max_db_cache));
39     }
40+    if constexpr (sizeof(void*) != 4) {

ajtowns commented at 10:57 am on February 28, 2026:

Would suggest using if constexpr (sizeof(void*) >= 8) { similar to dbwrapper.cpp (which uses < 8) here.

in src/node/caches.cpp:41 in 6b0210ebe2

36@@ -37,6 +37,11 @@ size_t CalculateDbCacheBytes(const ArgsManager& args)
37         constexpr auto max_db_cache{sizeof(void*) == 4 ? MAX_32BIT_DBCACHE : std::numeric_limits<size_t>::max()};
38         return std::max<size_t>(MIN_DB_CACHE, std::min<uint64_t>(db_cache_bytes, max_db_cache));
39     }
40+    if constexpr (sizeof(void*) != 4) {
41+        if (const auto total_ram{GetTotalRAM()}; total_ram && *total_ram >= HIGH_DEFAULT_DBCACHE_MIN_TOTAL_RAM) {

ajtowns commented at 10:58 am on February 28, 2026:

if ((GetTotalRAM().value_or(0)) >= HD_DBC_M_T_R) { ?

in src/qt/optionsmodel.cpp:472 in 6b0210ebe2

468@@ -469,7 +469,7 @@ QVariant OptionsModel::getOption(OptionID option, const std::string& suffix) con
469                suffix.empty()          ? getOption(option, "-prev") :
470                                          DEFAULT_PRUNE_TARGET_GB;
471     case DatabaseCache:
472-        return qlonglong(SettingTo<int64_t>(setting(), DEFAULT_DB_CACHE >> 20));
473+        return qlonglong(SettingTo<int64_t>(setting(), HIGH_DEFAULT_DBCACHE >> 20));

ajtowns commented at 11:05 am on February 28, 2026:

Perhaps having a size_t DefaultDBCache() { ... } that performs the RAM logic and is also used here would make sense?

in src/init.cpp:506 in 6b0210ebe2

502@@ -503,7 +503,7 @@ void SetupServerArgs(ArgsManager& argsman, bool can_listen_ipc)
503     argsman.AddArg("-conf=<file>", strprintf("Specify path to read-only configuration file. Relative paths will be prefixed by datadir location (only useable from command line, not configuration file) (default: %s)", BITCOIN_CONF_FILENAME), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
504     argsman.AddArg("-datadir=<dir>", "Specify data directory", ArgsManager::ALLOW_ANY | ArgsManager::DISALLOW_NEGATION, OptionsCategory::OPTIONS);
505     argsman.AddArg("-dbbatchsize", strprintf("Maximum database write batch size in bytes (default: %u)", DEFAULT_DB_CACHE_BATCH), ArgsManager::ALLOW_ANY | ArgsManager::DEBUG_ONLY, OptionsCategory::OPTIONS);
506-    argsman.AddArg("-dbcache=<n>", strprintf("Maximum database cache size <n> MiB (minimum %d, default: %d). Make sure you have enough RAM. In addition, unused memory allocated to the mempool is shared with this cache (see -maxmempool).", MIN_DB_CACHE >> 20, DEFAULT_DB_CACHE >> 20), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
507+    argsman.AddArg("-dbcache=<n>", strprintf("Maximum database cache size <n> MiB (minimum %d, default: %d (%d if less than %d MiB system RAM detected)). Make sure you have enough RAM. In addition, unused memory allocated to the mempool is shared with this cache (see -maxmempool).", MIN_DB_CACHE >> 20, HIGH_DEFAULT_DBCACHE >> 20, DEFAULT_DB_CACHE >> 20, HIGH_DEFAULT_DBCACHE_MIN_TOTAL_RAM >> 20), ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);

ajtowns commented at 11:09 am on February 28, 2026:

Could just leave the memory detection to the .md file and report default: %d as whatever the default on the system is.

ajtowns commented at 11:11 am on February 28, 2026: contributor

Having a fairly simple bump to the dbcache seems better than adding scaling logic to me, fwiw (hi insta).

kevkevinpal commented at 3:02 pm on February 28, 2026: contributor

Concept ACK 6b0210e

I agree with Ajtowns, I think it makes more sense to have a simple bump in cache size instead of auto scaling.

kevkevinpal commented at 3:11 pm on February 28, 2026: contributor

We might want to add a release note since this will affect any nodes that currently do not have -dbcache set running on systems with greater than 4 GB RAM

dbcache: bump default from 450MB -> 1024MB if enough memory

If dbcache is unset, bump default from 450MB to 1024MB on 64-bit systems
that have at least 4GB of detected RAM.

5b34f25184

andrewtoth force-pushed on Feb 28, 2026

qt: show GetDefaultDBCache() in settings 027cac8527

doc: update dbcache default in reduce-memory.md c510d126ef

andrewtoth force-pushed on Feb 28, 2026

DrahtBot added the label CI failed on Feb 28, 2026

DrahtBot commented at 3:45 pm on February 28, 2026: contributor

🚧 At least one of the CI tasks failed. Task test ancestor commits: https://github.com/bitcoin/bitcoin/actions/runs/22523590140/job/65252087815 LLM reason (✨ experimental): Build failed during the Qt target (src/qt/optionsmodel.cpp) with a non-zero exit status from the cmake/make step.

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

doc: add release notes for dbcache bump 4ae9a10ada

andrewtoth force-pushed on Feb 28, 2026

sipa commented at 3:53 pm on February 28, 2026: member

ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb

andrewtoth commented at 3:55 pm on February 28, 2026: contributor

Thanks @ajtowns I took all your suggestions. Thanks @kevkevinpal added release notes.

ajtowns commented at 5:06 pm on February 28, 2026: contributor

ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb

Checked it gives 450 on a system with less than 4GB and 1024 on a system with more.

DrahtBot removed the label CI failed on Mar 2, 2026

hodlinator commented at 10:05 pm on March 2, 2026: contributor

If you want to avoid changing kernel behavior in this PR, it would be good to state so in the PR-description. “This change only changes bitcoind behavior, while kernel still defaults to 450 MiB.” https://github.com/bitcoin/bitcoin/blob/2702711c3a54b2ba9ae3781b61c90d28ee951de6/src/kernel/bitcoinkernel.cpp#L463 https://github.com/bitcoin/bitcoin/blob/2702711c3a54b2ba9ae3781b61c90d28ee951de6/src/kernel/bitcoinkernel.cpp#L1013

Please also use the correct “GiB” unit in PR title. (Edit: and correct all units in the PR description).

andrewtoth renamed this:
~~Bump dbcache to 1GB~~
Bump dbcache to 1 GiB
on Mar 2, 2026

darosior commented at 3:39 pm on March 4, 2026: member

Concept ~0 because i think it’s fine if this PR is merged as is, but i reject the premise that we should be supporting systems with very low memory through the default configuration.

I think the goal of supporting systems with low resources is better achieved with configuration presets (as was suggested in the meeting where this issue was discussed) than with complicated and surprising system resource detection baked into our code.

fanquake added this to the milestone 31.0 on Mar 5, 2026

fanquake commented at 5:22 pm on March 5, 2026: member

Put this on the milestone, to gather any more opinons/make a decision for v31.

achow101 commented at 6:22 pm on March 5, 2026: member

Concept ACK

yancyribbens commented at 8:21 pm on March 5, 2026: contributor

Concept ACK - Prefer incremental improvement

andrewtoth commented at 8:57 pm on March 5, 2026: contributor

i reject the premise that we should be supporting systems with very low memory through the default configuration @darosior I think we first need to establish what the minimum supported memory is that we support with default configuration. “Very low” can mean different things to different people. Currently we can support running indefinitely on 2GB VMs with default configuration. This is a popular cheap format (https://aws.amazon.com/ec2/instance-types/t2/) for running (not syncing) bitcoind. I don’t think that counts as “very low” memory (but others may disagree). The docs in reduce-memory.md can configure running a node in < 500MB of RAM, which I would call “very low”.

Bumping to 1GB of RAM without checking available memory will definitely break this 2GB usecase with default configuration, since we don’t clear the dbcache periodically anymore.

darosior commented at 9:07 pm on March 5, 2026: member

Fair enough, but bumping a default is always going to break default-compatibility for some use cases. Trying to avoid that means that going forward we won’t be able to bump a default without adapting the default to various systems. I don’t think this is the right direction. Instead we should set defaults such as to maximize the utility of our software on the vast majority of systems, and provide reasonable configuration instructions for people in the minority. In this instance, because Bitcoin Core is a relatively resource intensive software, i don’t think it’s reasonable to consider systems with 2GiB of RAM as part of the vast majority we need to support.

I don’t want to be a blocker for this particular PR and i’m happy to continue the more meta discussion of how we should set our defaults moving forward in a separate venue. (But if somehow my argument convinced you and you were to change this to a simple default bump i would gladly ACK it :p.)

yancyribbens commented at 9:43 pm on March 5, 2026: contributor

Fair enough, but bumping a default is always going to break default-compatibility for some use cases.

Good point. For systems I am willing to run core on, this bump seems reasonable. One suggestion is just to see who comes knocking after this change, and then try to weigh the argument for making this something that’s configurable? I Concept Acked this, so now I feel drawn in to the conversation. But I had thought trying to do the auto-dynamic memory thing was a can of worms. Although, my preference long-term would probably be something along the lines of a nob or a profile that can be configured for the hobbyists that want to run this on mininmal hardware..

andrewtoth commented at 10:19 pm on March 5, 2026: contributor

weigh the argument for making this something that’s configurable? @yancyribbens do you mean making -dbcache configurable? If so it is already a configuration option. This PR and discussion is about changing the default value for it.

yancyribbens commented at 11:31 pm on March 5, 2026: contributor

@yancyribbens do you mean making -dbcache configurable? If so it is already a configuration option. This PR and discussion is about changing the default value for it.

Oh, great! Then, I think if this breaks the default compatibility for some users, then they would simply need to adjust their configuration..

sipa commented at 11:34 pm on March 5, 2026: member

@yancyribbens It really helps to read PRs before commenting on them.

yancyribbens commented at 11:45 pm on March 5, 2026: contributor

@yancyribbens It really helps to read PRs before commenting on them.

Leave it up to @sipa to put me in my place, again. Fair point.

kevkevinpal commented at 3:10 am on March 6, 2026: contributor

reACK 4ae9a10

This looks good to me, I think it makes sense to continue to support low RAM systems and not do a simple bump.

This is good to get into the v31.0 release without being too complicated and revisit the autoscaling RAM in a later release if desired.

changes from last ack: - Release notes added - ajtowns suggestions

DrahtBot requested review from achow101 on Mar 6, 2026

DrahtBot requested review from darosior on Mar 6, 2026

ajtowns commented at 3:33 am on March 6, 2026: contributor

Concept ~0 because i think it’s fine if this PR is merged as is, but i reject the premise that we should be supporting systems with very low memory through the default configuration.

Been thinking about this some more. I still think it’s preferable this PR be merged as-is for 31.0, but a different approach could be:

choose defaults that give respectable performance on easy to obtain hardware; eg 1GB dbcache on an 8GB RAM machine
on startup, if the configuration settings have been left as defaults, check if they’re obviously unreasonable (dbcache is >25% of memory, prune is unset on mainnet and there’s only 20GB of diskspace, eg) and provide a startup error if so.
you can avoid the startup error by explicitly configuring the settings, even just setting to the same values as the defaults. ie saying “I know what I’m doing, shut up about it”

That lets us set the defaults to a single value that achieve reasonable performance on reasonable hardware, and leaves achieving great performance or running on unreasonable hardware with poor performance up to people to configure.

I feel like simple good-enough defaults and flexible configuration options is a better approach than trying to make the defaults automatically optimise themselves for the hardware, a la #34641. Having a check and an early error when we can detect that the good-enough defaults are probably not appropriate for the hardware would be a win on top of that, I think, while also not making things much more complex. For people who specifically want automatic optimisation of their config, then a third party tool (lopp’s bitcoin.conf generator?) or AI consultation would let them achieve that.

in src/node/caches.cpp:38 in 5b34f25184

33+static constexpr uint64_t HIGH_DEFAULT_DBCACHE_MIN_TOTAL_RAM{4096ULL << 20};
34 
35 namespace node {
36+size_t GetDefaultDBCache()
37+{
38+    if constexpr (sizeof(void*) >= 8) {

yancyribbens commented at 12:38 pm on March 6, 2026:

is this check for 64 bit system actually needed here? I believe it’s possible to run PAE kernel versions that allow for 32 bit systems to address 4+ Gigs of memory.

yancyribbens commented at 1:01 pm on March 6, 2026:

Also, along those lines, I think if you are running on i86 and have 4gib, it would be preferable to use the 1Gb cache size…

andrewtoth commented at 7:44 pm on March 6, 2026:

Maybe not necessary, but of course these users can always set the config themselves.

DrahtBot requested review from yancyribbens on Mar 6, 2026

in doc/reduce-memory.md:9 in c510d126ef

 5@@ -6,7 +6,7 @@ There are a few parameters that can be dialed down to reduce the memory usage of
 6 
 7 The size of some in-memory caches can be reduced. As caches trade off memory usage for performance, reducing these will usually have a negative effect on performance.
 8 
 9-- `-dbcache=<n>` - the UTXO database cache size, this defaults to `450`. The unit is MiB (1024).
10+- `-dbcache=<n>` - the UTXO database cache size, this defaults to `1024` (or `450` if less than `4096` MiB system RAM is detected). The unit is MiB (1024).

yancyribbens commented at 12:40 pm on March 6, 2026:

nit: technically this is checking for if is not 64bit and is less than 4096 MiB system RAM

DrahtBot requested review from yancyribbens on Mar 6, 2026

in doc/release-notes-34692.md:4 in 4ae9a10ada

0@@ -0,0 +1,6 @@
1+## Updated settings
2+
3+- The default `-dbcache` value has been increased to `1024` MiB from `450` MiB
4+  on systems where at least `4096` MiB of RAM is detected.

yancyribbens commented at 12:41 pm on March 6, 2026:

Same as previous nit (64 bit thing).

DrahtBot requested review from yancyribbens on Mar 6, 2026

ViniciusCestarii commented at 1:10 pm on March 6, 2026: none

One edge case to consider is how GetTotalRAM() determines available memory. On Unix systems it uses sysconf(_SC_PHYS_PAGES) * sysconf(_SC_PAGE_SIZE), which reports the host’s physical RAM, not the memory limit of the container.

For example, if a Docker container is started with --memory=1g on a host with 32 GB of RAM, this call will still return about 32 GB. As a result, the 4 GiB check passes and dbcache may be set to 1024 MiB, which can cause the container to run out of memory.

However, the container’s memory limit is exposed through cgroups. In this setup, /sys/fs/cgroup/memory.max correctly reports the container limit (for example, 1 GiB). Taking the minimum between GetTotalRAM() and the cgroup memory limit, when the latter is available, would address this issue for common container environments such as Docker.

svanstaa commented at 1:15 pm on March 6, 2026: none

ACK 4ae9a10

Reviewed the code, built and ran it. Can attest that it defaults to 1024 without the dbcache set, and still to 450 with dbcache=450.

Since I have no machine with less than 4GB available, tried to patch the GetTotalRAM function to set it to 2GB, but it did not work, since the dynamic linker never resolves it.

std::optional<size_t> GetTotalRAM() { return 2ULL * 1024 * 1024 * 1024; // pretend 2 GB }

Compile: g++ -shared -fPIC src/node/fake_ram.cpp -o fake_ram.so

Test with fake 2 GB RAM LD_PRELOAD=./fake_ram.so ./build/bin/bitcoind -regtest | grep -E “Cache|Mib”

$ ./build/bin/bitcoind –version | grep version Bitcoin Core daemon version v30.99.0-4ae9a10ada95 bitcoind

$ ./build/bin/bitcoind -regtest -dbcache=450 | grep -E “Cache|MiB”

2026-03-06T12:53:03Z Cache configuration: 2026-03-06T12:53:03Z * Using 2.0 MiB for block index database 2026-03-06T12:53:03Z * Using 8.0 MiB for chain state database 2026-03-06T12:53:03Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)

$ ./build/bin/bitcoind -regtest | grep -E “Cache|MiB” 2026-03-06T12:53:26Z Cache configuration: 2026-03-06T12:53:26Z * Using 2.0 MiB for block index database 2026-03-06T12:53:26Z * Using 8.0 MiB for chain state database 2026-03-06T12:53:26Z * Using 1014.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)

andrewtoth commented at 7:43 pm on March 6, 2026: contributor

It seems I may be too conservative when trying not to break use cases, since most other reviewers don’t seem to think it’s a big issue. I suppose there are likely very few users running on <4GB that are not already configuring their defaults and reading release notes. The defaults are meant for newbies who aren’t yet configuring, which are likely on higher RAM systems.

Nevertheless, this PR is meant to be a last minute sneak in to v31. There are already several ACKs, and those with suggestions explicitly said they do not mind it being merged as is. So, I’m going to leave it as is for now and hopefully a maintainer will merge before cutoff.

on startup, if the configuration settings have been left as defaults, check if they’re obviously unreasonable (dbcache is >25% of memory, prune is unset on mainnet and there’s only 20GB of diskspace, eg) and provide a startup error if so. @ajtowns Since #33333 we warn on oversized dbcache. I think it would make sense to tighten that up to an error.

achow101 commented at 7:45 pm on March 6, 2026: member

ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb

darosior commented at 7:56 pm on March 6, 2026: member

So, I’m going to leave it as is for now and hopefully a maintainer will merge before cutoff.

Wouldn’t that be surprising to merge the detection if it doesn’t work on containers:

As a result, the 4 GiB check passes and dbcache may be set to 1024 MiB, which can cause the container to run out of memory.

which are at least as common a setup as VMs are, which were used as the main argument for the detection in the first place:

Currently we can support running indefinitely on 2GB VMs with default configuration. This is a popular cheap format (https://aws.amazon.com/ec2/instance-types/t2/) for running (not syncing) bitcoind.

(In any case anybody technical enough to spin up a VM or a container is able to set a configuration option, it’s not like we are breaking a use case, but hey.)

Edited for clarity since apparently the condescending comment that ensued was genuine.

darosior commented at 8:04 pm on March 6, 2026: member

I opened #34763 as an alternative that only bumps the default without introducing the detection.

achow101 commented at 8:07 pm on March 6, 2026: member

which are at least as common a setup, as the one which was used as the main argument for the detection in the first place:

Currently we can support running indefinitely on 2GB VMs with default configuration. This is a popular cheap format (https://aws.amazon.com/ec2/instance-types/t2/) for running (not syncing) bitcoind.

(In any case anybody technical enough to spin up a VM or a container is able to set a configuration option, it’s not like we are breaking a use case, but hey.)

A VM is not the same as a container, and will present available memory differently. In the case with AWS VPSes, the machine will appear to have the specified amount of memory and not be affected by this issue.

achow101 merged this on Mar 6, 2026

achow101 closed this on Mar 6, 2026

darosior commented at 8:11 pm on March 6, 2026: member

A VM is not the same as a container

Oh, really?

andrewtoth deleted the branch on Mar 6, 2026

yancyribbens commented at 10:01 pm on March 6, 2026: contributor

Oh, really?

This actually goes back to when chroot was introduced in 1979 as a way to provide an isolated filesystem while still using the same host kernel. FreeBSD extended this idea to also include isolation for other devices in the form of Jails, which was sort of co-opted later in the form of linux containers. Containers also brought along a who ecosystem of reproducible install tools eg Docker. I’m still pretty found of jails though for their simplicity over containers, and of course less overhead than VMs. Anyway, there’s a pretty interesting detail of this here: https://hypha.pub/back-to-freebsd-part-1.

optout21 commented at 6:40 am on March 8, 2026: contributor

I feel like simple good-enough defaults and flexible configuration options is a better approach than trying to make the defaults automatically optimise themselves for the hardware, a la #34641.

I argue with that. A large number of bitcoin-core runners will give zero thought about RAM sizes and memory limits, and expect things to work, and if things don’t work optimally, they will blame the software. Even if there was concrete guidance offered, like “set dbcache to 20% of the available RAM” (there is no such guidance), most users would not comply. I think context-aware meaningful defaults are very useful. Context-aware estimated min/max values are also needed to be able to generate meaningful warnings in case user configuration is present, but nonsensical. I think context-aware defaults that try to cover a wider range of different systems (like #34641) are better overall. But for sure user configuration should be able to override everything.

optout21 commented at 7:05 am on March 8, 2026: contributor

on startup, if the configuration settings have been left as defaults, check if they’re obviously unreasonable (…) and provide a startup error if so.

Refusing to start on unreasonable values is an interesting idea. But I see inconsistency here: if we trust the software-decided reasonable-limits so much that it can even refuse to start, why not trust a default to be used? The logic/reliability to derive the optimal default and unreasonable limits are very similar.

To me it looks more consistent and useful to:

Derive meaningful context-aware default/min/max values, based on the available RAM (and possibly other parameters)
If no config is given, use the default, and state this in the logs to the user, alongside with all data points used (e.g. detected RAM amount).
If config is given, use that. Check against min/max values, and if it’s outside, warn in the logs (alongside with all data points used e.g. detected RAM amount). But attempt to run anyways.
React to some symptoms of incorrect settings, e.g. to high swapping, with appropriate diagnostics logs.

I think this gives the best combo for:

informed defaults for ’non-technical’ users (e.g. users of node-runner solutions but on custom hardware)
control and relevant data points for ’technical’ users
info in case of rare strange setups where the software misbehaves (extremly low or high memory, misdetected memory, etc.).

optout21 commented at 7:27 am on March 8, 2026: contributor

Post-merge-ACK 4ae9a10ada95ab8c1ab01472948d348d9538f3bb

A limited change of the single-value limit to a two-tier limit, benefiting IBD performance on (the majority?) non-low-memory systems, for v31. For the future a more elaborate calculation of optimal default value and meaningful range, and more informative logging would be beneficial.

Bump dbcache to 1 GiB #34692

Reviews

Conflicts