Since you are syncing an indexer at the same time (also since November?),
Yes I was, but stopping the indexer had negligible effects on algod performance.
Thanks for the heads up! I did indeed restart indexing with 2.8.0 as it promises “Enhancements to import performance.”
With the previous indexer I could only manage 10-15 blocks a minute (at block height ~15M). So it would take be between 1-2 standard Eras to complete.
Regarding speeding up algod on slow disks:
A good option to save disk I/O is
"CadaverSizeTarget": 0,
This disables the cadaver file, which is only useful to debug the agreement protocol, per this question
Another tip that helped me a bit (I think - hard to say as there is variance in the speed between blocks anyhow) was to move the node.log file to a ramdisk and symlink it to the data dir, so that the log is written to RAM and doesn’t compete for I/O.
Something else I changed that I hope won’t bite me in the behind:
LedgerSynchronousMode: 0
This does:
// LedgerSynchronousMode defines the synchronous mode used by the ledger database. The supported options are:
// 0 - SQLite continues without syncing as soon as it has handed data off to the operating system.
// 1 - SQLite database engine will still sync at the most critical moments, but less often than in FULL mode.
// 2 - SQLite database engine will use the xSync method of the VFS to ensure that all content is safely written to the disk surface prior to continuing. On Mac OS, the data is additionally syncronized via fullfsync.
// 3 - In addition to what being done in 2, it provides additional durability if the commit is followed closely by a power loss.
// for further information see the description of SynchronousMode in dbutil.go
My full config can be found here
… the things we do.