Bitcoin Forum

Generally, regardless of the program, one does a settings config. after install. So I am working my
way through Core v22.0 Settings < Options:

1. What is the function of the database cache in a non-pruned node? Given plenty of non-volatile memory space, is there an ideal value?
2. Ditto 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?