Draft
Conversation
Move the OS-dependent total RAM query from `common/system.cpp` into a dedicated `common/system_ram.cpp` translation unit and declare it in `common/system_ram.h`. Update call sites to include `common/system_ram.h` and rename `GetTotalRAM()` to `TryGetTotalRam()`. Add `common/system_ram` to `FILES_WITH_ENFORCED_IWYU` so this new source is checked at error level. Since we use it for more than just warnings now, make `system_ram_tests` require RAM detection instead of skipping when unavailable. Co-authored-by: sipa <sipa@bitcoincore.org> Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
The current `dbcache` policy is split across `node`, `qt`, and `kernel`. The node startup path already chooses between `450 MiB` and `1024 MiB` based on detected RAM, while `bitcoinkernel` and the Qt settings migration still use fixed `450 MiB` values. Move the default selection and oversized warning helpers into dedicated `node/dbcache` code and use them from all current callers. This keeps the existing default selection logic in one place and makes the other users follow that same policy. This also changes the low-memory oversized warning to use the shared default helper instead of a fixed `450 MiB` cap. It changes `bitcoinkernel` and the Qt migration on 64-bit systems with at least 4 GiB RAM, where they now use the same `1024 MiB` default as the node path instead of a fixed `450 MiB`. Co-authored-by: Luke Dashjr <luke-jr+git@utopios.org>
The fixed `-dbcache` default of 450 MiB is too high for small systems and too conservative for larger ones. Compute the automatic default as `std::clamp((max(total_ram - 2 GiB, 0) / 4), 100 MiB, 2 GiB)`. The 2 GB upper limit was chosen because it's still a lot faster than 1 GiB, but barely faster than 3 GiB. When RAM detection is unavailable, fall back to 4 GiB on 64-bit and 2 GiB on 32-bit. Use that fallback for default calculation and logging. Align oversized `-dbcache` warnings with this policy on low-memory systems. For total RAM below `FALLBACK_RAM_BYTES`, warn when the configured value exceeds the automatic default. Keep the 75% of total RAM warning cap for larger systems. Log the automatically selected default when `-dbcache` is not explicitly set. And now that we have warnings for excessive dbcache in the logs, we can remove the warning from `-dbcache` arg doc. Also assert the default `dbcache` never triggers the oversized warning. Co-authored-by: Pieter Wuille <pieter@wuille.net> Co-authored-by: willcl-ark <will8clark@gmail.com> Co-authored-by: ismaelsadeeq <abubakarsadiqismail@proton.me>
The automatic `dbcache` helper currently only models the IBD sizing formula. Prepare for a later runtime resize by letting `GetDefaultDBCache()` distinguish between IBD and steady-state sizing while keeping the current behavior as the default. Add unit coverage for the steady-state formula so both paths are exercised before callers start using it.
Automatic `dbcache` sizing currently keeps the IBD-sized chainstate cache after the node reaches steady state. Pass enough startup sizing context into `ChainstateManager` to recompute the automatic target when caches are rebalanced. Track the fixed index share separately so only the chainstate portion is reduced. When `-dbcache` was not set explicitly, update the chainstate cache budget in `MaybeRebalanceCaches()` based on whether IBD is still active. Explicit `-dbcache` values keep their configured size.
The runtime resize only happens on IBD exit, so unit tests alone do not show that the change is wired into the real startup and sync path. Add a debug-only `-mocktotalram` option so a functional test can force a deterministic automatic `dbcache` selection. Use it in a new functional test that keeps a node in IBD with an old chain, then mines a recent block and checks `getchainstates` for the reduced steady-state cache. Update the release notes to describe that the automatic `dbcache` value is reduced after IBD.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatic
-dbcachesizing currently keeps the larger initial block download allocation after sync completes, even though steady-state validation needs less chainstate cache. This leaves memory tied up longer than necessary and makes the automatic setting less adaptive to the node's actual operating phase.This series centralizes
dbcachedefault selection, makes the automatic value RAM-aware, and teachesChainstateManagerto recompute the automatic target when leaving initial block download. The runtime reduction only applies when-dbcachewas not set explicitly, preserves fixed index cache allocations, adds logging for the selected automatic value, and includes unit and functional test coverage using a debug-only-mocktotalramoverride.