Cardano Node 11.2.1 Cuts Memory Use During Ledger Snapshots

Intersect published Cardano Node 11.2.1 on November 10 as a maintenance pre-release for the 11.2 series. The release notes describe a fix for temporary memory spikes when the node saves ledger snapshots. They also report that the disk-backed LSM configuration met Ouroboros Praos performance requirements for block production.

Ledger Snapshots Use Less Memory

A Cardano node periodically saves a copy of the ledger state to disk so it can resume from that point after a restart. Previously, writing a snapshot could temporarily increase memory use by roughly the size of the snapshot itself. According to the release notes, 11.2.1 removes that spike. The chain database also stops retaining the initial ledger state in memory, which can save several hundred MiB on networks with large initial sets of unspent transaction outputs or delegations.

The release changes when snapshots are written as well. During initial synchronization, the node writes snapshots as soon as they are requested. It applies a randomized delay after catching up to the chain tip. On mainnet and Preprod, the maximum delay drops from six hours to one.

Intersect had previously identified a memory regression in the 11.1.x series and outlined a plan to bring usage closer to 11.0 levels. The snapshot fix addresses a specific source of peak memory use during a disk write. The amount saved during that operation depends on the size of the snapshot.

What Disk-Backed Storage Means for Stake Pools

Cardano’s UTxO-HD design lets a node keep part of its unspent transaction output data on disk. The release notes report that its LSM storage backend met the performance requirements of Ouroboros Praos, the protocol Cardano uses to produce blocks. The hardware table lists 24 GB of RAM for the in-memory configuration and 8 GB for the disk-backed configuration, with the lower minimum still being validated.

For a stake pool operator, the practical question is whether the node can use less RAM while meeting the protocol’s deadlines for producing blocks. Moving part of the ledger state to disk makes storage performance part of that calculation. A relay can help an operator evaluate the configuration, while a test on the hardware intended for block production can show how it behaves under that workload. Intersect recommends testing the LSM configuration before deploying it on a block-producing node.

[NEWSBREAK]

What Changes for Operators Moving From 11.1.x

The 11.2 series introduces a versioned format for published network configuration files. Existing flat configurations still work with 11.2 and can be converted with cardano-node config migrate. Nodes older than 11.2 cannot read the newly published files.

Wallets, explorers, and API services face a separate compatibility change when connecting to a node on the 11.2 series. The series removes versions 16 through 22 of the node-to-client protocol, along with queries that depended exclusively on those versions.