Since #33333 we warn at startup when -dbcache is likely too large for the system's memory. This adds the symmetric runtime hint for the opposite misconfiguration: a -dbcache too small for the node's working set.
When the coins cache grows past its size limit outside of IBD (CoinsCacheSizeState::LARGE on a periodic flush, or CRITICAL during block connection), it is fully emptied rather than synced. On a long-running node this is easy to hit with a small -dbcache, and it has a real cost: the cache never stays warm, block connection slows down, and every eviction cycle rewrites a large part of the UTXO set into LevelDB, causing compaction churn and sustained write amplification on the underlying disk.
Today this situation is invisible unless the user runs with -debug=coindb or attaches to the Linux-only utxocache:flush tracepoint. I recently diagnosed a stock Umbrel node (dbcache=450 with txindex and blockfilterindex enabled) whose container had averaged roughly 2 MB/s of disk writes over three weeks while fully synced at tip. The only clue in default logs was the cache= value in UpdateTip lines sitting pinned at the same number for hours. A one-line hint would have made that diagnosis trivial, and would point the many node-in-a-box users running overridden defaults at the actual fix.
The warning:
- only fires for a size-pressure eviction (not
FORCE_FLUSH, not periodic syncs, not prune flushes), - is suppressed during IBD, where filling the cache is expected,
- is suppressed for historical (assumeutxo background) chainstates, and
- is logged at most once per run to avoid log spam.
The new functional test fills a 4 MiB coins cache past its limit with MiniWallet transactions and checks that the warning appears.
