Monitoring and Pruning
Monitoring
Monitor your Full node using the instructions in the Node Monitoring and Metrics section.
The default metrics port is 9184. To change the port, edit your fullnode.yaml file.
Object Pruning
IOTA adds new object versions to the database as part of transaction execution. This makes previous versions ready for garbage collection. However, without pruning, this can result in database performance degradation and requires large amounts of storage space. IOTA identifies the objects that are eligible for pruning in each checkpoint, and then performs the pruning in the background.
You can enable pruning for an IOTA node by adding the authority-store-pruning-config config to fullnode.yaml file:
authority-store-pruning-config:
# Number of epoch dbs to keep
# Not relevant for object pruning
num-latest-epoch-dbs-to-retain: 3
# The amount of time, in seconds, between running the object pruning task.
# Not relevant for object pruning
epoch-db-pruning-period-secs: 3600
# Number of epochs to wait before performing object pruning.
# When set to 0, IOTA prunes old object versions as soon
# as possible. This is also called *aggressive pruning*, and results in the most effective
# garbage collection method with the lowest disk usage possible.
# This is the recommended setting for IOTA Validator nodes since older object versions aren't
# necessary to execute transactions.
# When set to 1, IOTA prunes only object versions from transaction checkpoints
# previous to the current epoch. In general, when set to N (where N >= 1), IOTA prunes
# only object versions from checkpoints up to `current - N` epoch.
# It is therefore possible to have multiple versions of an object present
# in the database. This setting is recommended for IOTA Full nodes as they might need to serve
# RPC requests that require looking up objects by ID and Version (rather than just the latest
# version). However, if your Full node does not serve RPC requests you should then also enable
# aggressive pruning.
num-epochs-to-retain: 0
# Advanced setting: Maximum number of checkpoints to prune in a batch. The default
# settings are appropriate for most use cases.
max-checkpoints-in-batch: 10
# Advanced setting: Maximum number of transactions in one batch of pruning run. The default
# settings are appropriate for most use cases.
max-transactions-in-batch: 1000
Transaction pruning
Transaction pruning removes previous transactions and effects from the database. IOTA periodically creates checkpoints. Each checkpoint contains the transactions that occurred during the checkpoint and their associated effects.
IOTA performs transaction pruning in the background after checkpoints complete.
You can enable transaction pruning for your Full node or Validator node by adding num-epochs-to-retain-for-checkpoints
to the authority-store-pruning-config config for the node:
authority-store-pruning-config:
num-latest-epoch-dbs-to-retain: 3
epoch-db-pruning-period-secs: 3600
num-epochs-to-retain: 0
max-checkpoints-in-batch: 10
max-transactions-in-batch: 1000
# Number of epochs to wait before performing transaction pruning.
# When this is N (where N >= 2), IOTA prunes transactions and effects from
# checkpoints up to the `current - N` epoch. IOTA never prunes transactions and effects from the current and
# immediately prior epoch. N = 2 is a recommended setting for IOTA Validator nodes and IOTA Full nodes that don't
# serve RPC requests.
num-epochs-to-retain-for-checkpoints: 2
# Ensures that individual database files periodically go through the compaction process.
# This helps reclaim disk space and avoid fragmentation issues
periodic-compaction-threshold-days: 1