Skip to content

Initial Configuration

Eric Voskuil edited this page Mar 28, 2017 · 17 revisions

Optimal initial block download is very different from operational configuration. The following settings are recommended and otherwise defaults are sufficient. See additional information below. and also why manual configuration is required for initial block download.

[log]
# debug_file = debug.log
# error_file = error.log
# archive_directory = archive
rotation_size = 10000000

[network]
inbound_connections = 0
outbound_connections = 3
channel_expiration_minutes = 60

[database]
# directory = blockchain
flush_writes = false
# cache_capacity = 10000

[blockchain]
cores = 32
# checkpoint = 0000000000000000014083723ed311a461c648068af8cef8a19dcd620c07a20b:450000

[node]
block_poll_seconds = 1
relay_transactions = false

[server]
query_workers = 0
heartbeat_interval_seconds = 0
block_service_enabled = false
transaction_service_enabled = false

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). The necessary settings are shown above, though appropriate paths must be selected.

Network

Managing peers is essential during initial block download. More than 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. However performance can be negatively impacted with more than 32 cores, as the cost of distributing the work starts to exceed the benefit. 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

These settings disabled the server endpoints. This reduces unnecessary endpoint services and and transaction parsing.

Clone this wiki locally