Best Practices for set up node

Intermediate

Best Practices for set up node

This tutorial provides best practices for setting up a node to make it more convenient for DApps and node hosts. It includes a list of useful settings and configurations that can be adapted to suit individual use cases. Some of the settings discussed include log level, db_backend, max_num_inbound_peers, max_num_outbound_peers, metrics, and app.toml. The tutorial also discusses the different pruning options and the iavl-disable-fastnode and iavl-cache-size settings. By following these best practices, you can ensure that your node is optimized for performance and efficient resource utilization.

In order to make it more convenient for DApps and node hosts to set up a node, we have put together a list of useful settings and configurations. Feel free to refer to this guide and adapt settings to suit your own use cases. For a sample config check here.

config.toml

Log_level

info Depending on the needs of your application it is ok to stick to info (default), but do consider setting up log-rotation for your logs, and archive logs after a certain amount of time or size, e.g. use a cron job with weekly rotation or until your file size hits ~5GB.
set to debug only for debugging purposes, turn off after you are finished with debugging.

db_backend

Since 1.0.2 there is another db parameter in app.toml as well. Be sure to make these 2 parameters the same to avoid issues.

goleveldb (default) db for low / medium level traffic use case. The reason being there can be some lock contention, especially with P2P.
rocksdb suited for a lot of use-cases, especially for high query load ~ few M / day. Has a better balance between rpc queries and p2p at high traffic. Note thatRocksdb however might have a slower startup time and requires a higher memory allocation.

Seeds and persistent_peers

max_num_inbound_peers For node providers the number of inbound peers can be set to a higher value for example 50.
max_num_outbound_peers For users on a private network set a higher number of outbound peers to 30 for example.
After peers are connected, set it back to its default value. Note that some trial values might be needed to get it right.
seeds Set the list of seeds as instructed in the Running nodes section to connect to.
persistent_peers is especially useful when using State-sync to pull snapshots from.

send_rate and recv_rate

Free to tweak to a higher bytes/sec value, if your networking allows this, e.g. 51200000

timeout_broadcast_tx_commit

Freely tweak this parameter. Set to a slightly higher value, such as 20s to wait for a tx to be committed during / broadcast_tx_commit. Be careful a value larger than 10s will result in increasing the global HTTP write timeout, which applies to all connections and endpoints.

max_num_inbound_peers and max_num_outbound_peers

max_num_inbound_peers For node providers the number of inbound peers can be set to a higher value for example 50.
max_num_outbound_peers For users on a private network set a higher number of outbound peers to 30 for example.
After peers are connected, set it back to its default value. Note that some trial values might be needed to get it right.

Metrics

Prometheus provides real-time metrics used for event monitoring and alerting. Prometheus metrics can be served on the Cronos chain. To enable the Prometheus metrics, you will need to set instrumentation.prometheus=true in the config.toml file manually.

Metrics will be served under …/metrics on 26660 port by default, e.g. localhost:26660/metrics. The listening address can be changed in the config.toml file (prometheus_listen_addr).

Sample Settings:

#######################################################
###       Instrumentation Configuration Options     ###
#######################################################
[instrumentation]

# When true, Prometheus metrics are served under /metrics on
# PrometheusListenAddr.
# Check out the documentation for the list of available metrics.
prometheus = true

# Address to listen for Prometheus collector(s) connections
prometheus_listen_addr = ":26660"

# Maximum number of simultaneous connections.
# If you want to accept a larger number than the default, make sure
# you increase your OS limits.
# 0 - unlimited.
max_open_connections = 3

# Instrumentation namespace
namespace = "tendermint"

app.toml

Pruning

default Normal usage can just be set to default. In the Cosmos SDK this is defined as:

PruneDefault = NewPruningOptions(362880, 100, 10)

meaning the app will keep the latest 362880 versions (around 21 days by 5 secs block time), and then only keep 1 version for every 100 blocks past the keepRecent period( the rest will be put into the pruning list), and then execute the pruning every 10 blocks.

everything if you only need to do transaction broadcasting and only need the last blocks.
nothing for DApps that want to be able to query information at a certain known blockheight. Note that this is only needed for archive nodes.

iavl-disable-fastnode and iavl-cache-size

During the dragonberry patch and the upgrade to 0.8.2 and 0.8.3, we enabled the iavl-disable-fastnode config parameter. This provides the option to disable the iavl fastnode indexing migration, as a migration will take multiple hours to complete.

iavl-disable-fastnode = false is the default setting and performs the migration. This might take a while. So be prepared in advance and schedule this migration downtime. In case you use a snapshot that has performed migration already (e.g. quicksync), leave the value to false
iavl-disable-fastnode = true if you want to disable the fast indexing, and skip the migration. Only use this in case you really are not able to perform the migration now.
iavl-cache-size set to 781250 works well as our testing has shown.

app-db-backend

As of v1.0.0 we support golevelDB and rocksDB in a single binary, hence we allow to select the backend with the app-db-backend parameter. If not filled in it will use a fallback option. First fallback is the deprecated compile-time types.DBBackend value. Second fallback (if the types.DBBackend also isn’t set), is the db-backend value set in config.toml.

app-db-backend = "rocksdb" or "golevelsdb"

API

enable = true to enable the API server
swagger = true to setup the swagger endpoint

Json-RPC

api = "eth,txpool,web3" Set to the namespaces you wish to use, optionally add personal,net,debug to that list.
evm-timeout Freely tweak this parameter. Set to a slightly higher value, such as 60s to avoid timeouts on eth_calls.
http-timeout Freely tweak this parameter. Set to a slightly higher value, such as 60s to avoid read/writes timeouts of the http json-rpc server.
http-idle-timeout. Freely tweak this parameter. Set to a slightly higher value, such as 120s to avoid idle timeout of the http json-rpc server.

Debug Method

debug_trace allows nodes to return the trace of block and transaction details. In order to enable debug_trace for your node on the Cronos chain, two places need to be configured correctly under app.toml.

Sample Settings:

# default: the last 362880 states are kept, pruning at 10 block intervals
# nothing: all historic states will be saved, nothing will be deleted (i.e. archiving node)
# everything: 2 latest states will be kept; pruning at 10 block intervals.
# custom: allow pruning options to be manually specified through 'pruning-keep-recent', and 'pruning-interval'
pruning = "everything"

[evm]

# Tracer defines the 'vm.Tracer' type that the EVM will use when the node is run in
# debug mode. To enable tracing use the '--evm.tracer' flag when starting your node.
# Valid types are: json|struct|access_list|markdown
tracer = ""


[json-rpc]

# API defines a list of JSON-RPC namespaces that should be enabled
# Example: "eth,txpool,personal,net,debug,web3"
api = "eth,net,web3,txpool,personal,debug"

In addition, it should run as cronosd start --trace in cronosd start command (archived node). For the resources needed for --trace flag in Cronos mainnet, the mem usage is slightly higher than the others but 64GB should be enough.

Cronos