Since -maxmempool is 450 MB by default it's quite possible for a user to accidentally OOM a low
memory device if they increase -dbcache beyond the default.
<img width="563" alt="schermafbeelding 2018-09-06 om 17 02 40" src="https://user-images.githubusercontent.com/10217/45166219-c9c4f700-b1f6-11e8-9ee5-14b8b3a9830b.png">
362 | @@ -363,7 +363,7 @@ void SetupServerArgs() 363 | gArgs.AddArg("-conf=<file>", strprintf("Specify configuration file. Relative paths will be prefixed by datadir location. (default: %s)", BITCOIN_CONF_FILENAME), false, OptionsCategory::OPTIONS); 364 | gArgs.AddArg("-datadir=<dir>", "Specify data directory", false, OptionsCategory::OPTIONS); 365 | gArgs.AddArg("-dbbatchsize", strprintf("Maximum database write batch size in bytes (default: %u)", nDefaultDbBatchSize), true, OptionsCategory::OPTIONS); 366 | - gArgs.AddArg("-dbcache=<n>", strprintf("Set database cache size in megabytes (%d to %d, default: %d)", nMinDbCache, nMaxDbCache, nDefaultDbCache), false, OptionsCategory::OPTIONS); 367 | + gArgs.AddArg("-dbcache=<n>", strprintf("Set database cache size in megabytes. During initial sync memory from the mempool is added (see -maxmempool). (%d to %d, default: %d)", nMinDbCache, nMaxDbCache, nDefaultDbCache), false, OptionsCategory::OPTIONS);
Use the same terminology found below?https://github.com/bitcoin/bitcoin/blob/a9b242c53beb3be45e9d49af965bec835b3a7abc/src/init.cpp#L475
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
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
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).
