Tweaked the message to use "initial block download" instead of "initial sync" and use <n> megabytes convention. Also keeping (4 to ..., default: 450) directly after the first sentence, instead of at the very end (I think that's more readable).

Would the same OOM issue also be encountered during periods of time when mempools are full and not just in IBD? Maybe just clarify that the process can use up to dbcache + maxmempool space?

Agree with @skeees.
Users need to be aware that MAXMEMPOOLLIMIT+DBCACHE is what they should count for, regardless of IBD/In-sync.

But the – in this PR – updated -dbcache message seems to make it more clear.

utACK 2f631f0

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

Conflicts

No conflicts as of last run.

I personally don't think the message is clear enough to prevent users from over-allocating. Perhaps something along the lines of: "During initial block download, the amount of memory used may be up to maxmempoollimit + dbcache". ? Or something like this?

That's not just the case during IBD.

At any point in time, the total memory is limited by the headers in memory, network buffers, validation caches, UTXO set cache, mempool, plus some overhead.

When the mempool limit is not reached, the UTXO set cache is allowed to grow and use the mempool space as well, but this shouldn't affect users' expectations of memory usage. It'd also independent of IBD or not.

Ok, I tried a new wording:

  -dbcache=<n>
       Maximum database cache size <n> megabytes (4 to 16384, default: 450). In
       addition, unused mempool memory is shared for this cache (see
       -maxmempool).

Rebased after #15163, using MiB now.