I managed to stop bitcoin (it was pretty much unresponsive while trashing the disk, allowing for a mouse click every minute or so) and had to find the configuration settings, which are not in bitcoin.conf. That file is empty.
I found the settings in the registry, and I modified this setting to read 4096:
nDatabaseCache
You probably shouldn't be modifying the registry values. Those are Qt specific settings, if you ever run the bitcoind rather than bitcoin-qt, then those settings won't transfer. Only bitcoin.conf is universal to both.
The bitcoin.conf file is supposed to be empty, it has no settings to start with. You add things to it. So you would add the dbacache setting as it is not already there.
Anyway, I could be looking into moving the chainstate to a SSD, but I'd like to know the amount of writes it receives before doing so. Is it going to wear down an SSD fast (seeing as SLC is suggested)?
There are fewer writes with a higher dbcache. While I don't have exact numbers, with modern hardware you will probably move on to newer hardware before seeing any noticeable degraded performance. And SLC lasts longer too.
As mentioned, I set the buffer to 4096, and bitcoin now uses 5.6GB of memory. I guess there must be some extra memory consumed that scales with the buffer setting (besides the buffer itself).
Yes. dbcache is just the database cache. There is other memory being used that do not have user configurable parameters.
Progress is now at 80% (up from 58% yesterday) so I guess a week more and I am done (if I don't do the chainstate optimisation). And if the chainstate is only about 4GB, maybe offer a fast sync, having bitcoin temporarily cache the chainstate in memory and only do bulk writes occasionally? That way, rotating disks would be able to keep up during synchronization.
IIRC the database uncompressed in memory (leveldb does some compression on disk), is 6 or 7 GB. With dbcache=8000, the whole thing fits in memory. This significantly boosts performance because it basically never gets flushed to disk. Perhaps there could be a dynamic dbcache thing where Core tries to determine how large it should be, but no one has done that yet. For now, the default is low so that Core works on low end hardware too.
I merely feel there is basis for optimizations so bitcoin synchronization could run much better on rotating disks, and to use less memory than 5+GB while doing so.
Feel free to try to do this yourself. Every release contains several optimizations but at the same time, we are fighting against blockchain growth. If we improve sync time by 20%, but the blockchain grows 20% larger, then it's a wash and the sync time doesn't change. It's hard to make IBD go faster, but there are continual improvements to try to make it faster.