Bitcoin Core < Settings < Options

Usually, after installing any software, you go through the settings config. I'm checking out the settings in Core v22.0 under Settings < Options: 1. What's the purpose of the database cache in a non-pruned node? If we've got loads of non-volatile memory available, what’s the best value to set it to? 2. Same question goes for "Number of script threads verifications."

Are you talking about dbcache? The default value for dbcache is 100mb but it should depend on your memory RAM size and I use it to speed up the syncing process on the Bitcoin core whether it is a pruned or non-pruned node. Plus why use v22.0 that's old version of Bitcoin core the current recent one is 27.1 you should download the latest one if you don't want to experience some syncing issues.

During the initial block download, Bitcoin Core validates all of the blocks and builds the chainstate as it synchronizes. There are a lot of operations within the chainstate as the blocks are being synchronized and hence they're constantly being added and removed. Hence, dbcache will cache the chainstate to ensure speedy access of it in the memory and hence it allows the client to synchronize faster. The ideal value is less than your ram, ensure that you're leaving enough ram for your OS and other processes. I personally go for 4gb when I've got an 8gb computer. Don't have to change the value. Bitcoin Core automatically uses as many threads as your CPU have, minus one.

That config's actual label is "Script Verification Parallelization" which is mainly used when parallel script validation is required like when a new block is included. This hits hard a node in IBD during its script verification of newest block heights that aren't part of "assumedvalid" blocks. Default is good enough for most systems. But if you think that your machine can't handle it, (e.g.: Whole PC is lagging starting 85~90% of IBD), you can set it to a negative value to leave one plus that much threads.

Simply put: it reduces disk reads and writes. If you have loads of RAM the OS can handle read-cache, but the OS won't cache writes the way Bitcoin Core does when dbcache is large enough (larger than chainstate, currently about 12 GB). This has nothing to do with non-volatile memory. How did you even come up with that?

Confirmed. I am talking about dbcache which I see has a GUI config. I set it for 8 GB, probably overkill, but I have lots of RAM headroom, so "no harm, no foul." Thanks for the reminder that my Core is out of date. As you know, from my post on signature verification I am rectifying that. For two years, I ran Core 24/7 where my M.O. was "set it and forget it." Now I am digging deeper and paying attention to details.

1. Any idea why "minus one (core)" when script threads are automatically assigned? Perhaps it's just being conservative to not impinge on other user functions? 2. I am building a Full Node glossary, which I'll transfer to a spreadsheet, and now I add the term "chainstate." Per ChatGPT 4o, is this a valid definition? Brief: In the context of the BTC blockchain, the "chain state" refers to the current state of all unspent transaction outputs (UXTO's) at a given point in time. Extended: It is a snapshot that represents the set of all active balances and addresses that can be spent in future transactions. The chain state is continually updated as new blocks are added to the blockchain, reflecting the latest valid transactions. Further, I see that the chain state is stored in permanent memory, I'm assuming, when a block is finalized and added to the height, but that during processing, the chain state is cached in RAM, thus the benefit of increasing RAM to increase efficiency. Agree?

What is the approximate range of data, minimum to maximum,  as a function of dbcache in RAM? Yes, I stand corrected, the dbcache resides in volatile memory, but when a block is written, it resides in non-volatile memory. Correct? (PS. I came up with that because I'm 71 years old, and sometimes I get confused).

The main thread is already being occupied by your Bitcoin Core instance. The -1 is used to account for that. Pegging it to the number of cores instead of the number of CPU threads partially accounts for the latter. Chainstate gets flushed periodically during initial block download when it is filled. During processing, part of the chainstate can get cached in your RAM, which means that you're less dependent on your I/O speed since the RAM is way faster.