Bitcoin Core < Settings < Options ?

[Noob_Is_Relative]

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."

[BitMaxz]

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.

[ranochigo]

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?

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.

2. Ditto for "Number of script threads verifications."

Don't have to change the value. Bitcoin Core automatically uses as many threads as your CPU have, minus one.

[nc50lc]

2. Ditto for "Number of script threads verifications."

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.

[LoyceV]

1. What is the function of the database cache in a non-pruned node?

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).

Given plenty of non-volatile memory space, is there an ideal value?

This has nothing to do with non-volatile memory. How did you even come up with that?

[Noob_Is_Relative]

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.

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.

[Noob_Is_Relative]

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?

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.

2. Ditto for "Number of script threads verifications."

Don't have to change the value. Bitcoin Core automatically uses as many threads as your CPU have, minus one.

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?

[Noob_Is_Relative]

1. What is the function of the database cache in a non-pruned node?

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).

Given plenty of non-volatile memory space, is there an ideal value?

This has nothing to do with non-volatile memory. How did you even come up with that?

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).

[ranochigo]

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?

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.

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?

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.