#35620 leveldb: move unused block-cache budget to write buffers

full analysis

https://github.com/bitcoin/bitcoin/pull/35620 · l0rinc · +5/-2 in 1 files, 2 commits · labels: UTXO Db and Indexes, Resource usage, Needs rebase · draft

Goal

  • Stop reserving database cache budget for an unused block cache on 64-bit systems
  • Direct the unused cache budget toward database write buffers instead

This PR adjusts LevelDB cache options in CDBWrapper so that 64-bit platforms allocate a zero-capacity block cache and direct the remaining DB cache budget to write buffers. Because LevelDB uses mmap for uncompressed table files on 64-bit systems, table blocks are not inserted into the block cache. On 32-bit platforms, where mmap is disabled, the existing block-cache allocation is preserved.

Problem: On 64-bit platforms, CDBWrapper reserves half of each database cache budget for LevelDB's block cache, which sits largely empty because mmap-backed uncompressed table blocks bypass it.

Category: Validation (#45 of 48)

P4 · cleanup

  • P4 because reindexing benchmarks showed no meaningful speedup on SSDs
  • Reindex benchmarks showed a slight slowdown on magnetic hard drives
  • Tuning internal cache ratios without a measurable performance win is marginal

P4 because benchmarks showed no meaningful speedup during reindex-chainstate on SSDs and showed a slight slowdown on HDD. Tuning internal cache ratios that show no measurable performance win is marginal.

Membership: Changes CDBWrapper options in src/dbwrapper.cpp, which manages LevelDB configuration for chainstate and block index databases.

Factors: security/stability 0, bug 0, performance 0, user value 0, leverage 0

Reviewability: Stale: Needs rebase

  • Wait for author update: the PR has merge conflicts and is drafted to investigate regressions

The PR has merge conflicts with master and the author has been silent for 76 days after putting the PR into draft to investigate regressions.

Author status: silent since 2026-07-02 after indicating they would draft the PR to investigate HDD performance and test a cleaner removal

Open concerns:

  • Reviewers questioned keeping special-cased logic and complexity for 32-bit platforms given the project's direction.
  • sedited questioned whether giving indexes more write buffer than the 8 MiB default provides any benefit.
  • HDD benchmark runs showed a slight slowdown (1.02x - 1.03x), prompting the author to mark the PR draft for further investigation.

Agreement: Mild

  • Questioned maintaining special-cased logic for 32-bit systems (sedited, fanquake)
  • Questioned whether giving indexes larger write buffers provides any benefit (sedited)
  • Author put the PR in draft to investigate hard drive regressions and cleaner options (l0rinc)

Mild: reviewers questioned 32-bit branching and index buffer increases; author planned a broader cleanup but has not pushed.

sedited and fanquake questioned the architecture-specific branching for 32-bit systems and questioned the payoff of larger write buffers for indexes. The author agreed a simpler, broader removal would be cleaner, but has not followed up.

  • sedited asked: 'Is the extra case for 32bit systems really worthwhile? Seems like a lot of infrastructure for something that only pays off on a single architecture.'
  • fanquake pointed to #32375 and questioned adding new 32-bit code.
  • l0rinc agreed with reviewers and noted they would draft the change and run further tests.

Review verdicts (DrahtBot): 0

Files

0 lines under test/bench/ci.

  • src/dbwrapper.cpp +5/-2

Card

PR 35620 adjusts CDBWrapper to set a zero-capacity LevelDB block cache on 64-bit platforms and reallocates the freed budget to write buffers, avoiding wasted cache allocation for mmap-backed uncompressed tables. Extensive reindex benchmarks on SSDs showed no performance change, and HDD tests showed minor regressions. Reviewers questioned the need for 32-bit branching and suggested simplifying cache allocation entirely, which the author agreed to investigate before going silent. The PR is currently in draft, has merge conflicts, and is stale.

Data

dossier JSON · extract JSON · model openrouter/google/gemini-3.8-flash, generated 2026-09-17T16:19, confidence high, input hash dc98de6ccf8f3e61