Initial Configuration

The default settings are close to optimal for initial block download. Once complete settings should be changed to recommended operational configuration. See also why manual configuration is required for initial block download.

Log

The debug log can get large and impact performance if not managed. The most important setting is rotation_size as a nonzero value enabled log rotation. It is also helpful to maintain the debug log on an SSD and to rotate logs onto a disk other than that for the blockchain (SSD or HDD).

Network

Managing peers is essential during initial block download. More than two or three peers leads to excessive redundant block downloading, which can be seen in the debug log. Enabling incoming peers during initial block download creates unnecessary network overhead. Expiring channels periodically can be helpful in removing peers that are (or become) slow in responding to block requests.

Database

The database should be stored on an SSD for optimal performance. Having flush_writes enabled significantly slows block download. For machines with less than 128 GB RAM a nonzero cache_capacity can improve performance. For an 8 GB machine about 10000 is recommended.

Blockchain

The number of cores should generally be left at the default of zero. Setting a checkpoint will cause the most costly aspects of block validation to be bypassed until that checkpoint is reached.

Node

Setting block_poll_seconds = 1 for the small/early blocks prevents unnecessary delays between block polling. Otherwise there will be notable pauses every 2000 headers (or 500 blocks). As the blocks get larger this should be increased to 5 seconds at around block 200,000, 10 seconds at 300,000 and 15 seconds at 400,000. These are just approximations but with a low value you can get a lot of redundant blocks. Transaction relay should be disabled until the node is synchronized.

Server

Server endpoints should be disabled. This reduces unnecessary endpoint services and and transaction parsing.