How to use --trie-cache-gens value as performance tunning on downloading the blockchain (Geth)?

Question

I would like to know how to use a specific command in geth.

Geth lists "Performance tuning options:

--trie-cache-gens value (number of trie node generations to keep in memory - default: 120).

Thing is, I have a HDD that is almost always 99% while I have used 2048 cache option to speed up things. While using chrome also, I am using 63% memory. I have 8GB ram memory.

How can I use trie-cache-gens to tune my computer to speed download the blockchain? Should I increase from it's default value of 120? How much can I speed it up before I run out of memory? Is there some math I can make or just try it some?

Can it speed it up by much?

Thanks in advance for the answers.

Answer 1

Short answer: no amount of tuning will get an HDD to perform acceptably, you'll need an SSD.

Longer answer: From discussions with geth devs, multi-node operators, and my own tuning experiments:

PERFORMANCE TUNING OPTIONS:
--cache value            Megabytes of memory allocated to internal caching (default: 1024)
--cache.database value   Percentage of cache memory allowance to use for database io (default: 50)
--cache.trie value       Percentage of cache memory allowance to use for trie caching (default: 25)
--cache.gc value         Percentage of cache memory allowance to use for trie pruning (default: 25)
--trie-cache-gens value  Number of trie node generations to keep in memory (default: 120)

• Set --cache to a low value like 256 (default: 1024). 50% of this value is assigned to leveldb for file caching and it also changes when golang runs garbage collection for geth which can lead to much more RAM usage than expected if you have a high cache value. A low value basically tells the kernel of your OS to handle filesystem caching instead of geth. Your kernel will utilize unallocated RAM to cache frequently accessed files anyway, and it will be better at it than geth.
• Set --trie-cache-gens to a low value like 10 (default: 120)

UPDATES:

• 2018/12/28: Continuing to test with a low --cache value it appears leveldb database size grows much faster than with a high cache value, although I am not certain why changing cache value would change permanent storage space required.