The node_size parameter determines the size of database caches. Larger database caches decrease disk I/O requirements at a cost of higher memory requirements. Ripple recommends you always use the largest database cache your available memory can support. See the following table for recommended settings.
Available RAM for rippled node_size value Notes
< 8GB tiny Not recommended
32GB huge Recommended for production servers
Node DB Type
The type field in the node_db section of the rippled.cfg file sets the type of key-value store that rippled uses to persist the XRP Ledger in the ledger store. You can set the value to either rocksdb or nudb.
rippled offers a history sharding feature that allows you to store a randomized range of ledgers in a separate shard store. You may want to configure the shard store to use a different type of key-value store than the ledger store. For more information about how to use this feature, see History Sharding.
RocksDB vs NuDB
RocksDB requires approximately one-third less disk storage than NuDB and provides a corresponding improvement in I/O latency. However, this comes at a cost of increased memory utilization as storage size grows. NuDB, on the other hand, has nearly constant performance and memory footprint regardless of storage.
rippled servers that operate as validators should keep only a few days’ worth of data or less. Ripple recommends using RocksDB for validators. For all other uses, Ripple recommends using NuDB for the ledger store.
RocksDB has performance-related configuration options you can modify to achieve maximum transaction processing throughput. (NuDB does not have performance-related configuration options.) Here is an example of the recommended configuration for a rippled server using RocksDB:
XRP Ledger Network Data Integrity
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce proof trees or ledger deltas. Since rippled servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
Shard Store Configuration
To configure your rippled to store shards of ledger history, add a shard_db section to your rippled.cfg file.
Shard Configuration Example
The following snippet from an example rippled.cfg file shows the configuration fields for adding sharding to a rippled server:
Tip:Ripple recommends using NuDB for the shard store (type=NuDB). NuDB uses fewer file handles per shard than RocksDB. RocksDB uses memory that scales with the size of data it stores, which may require excessive memory overhead.
Tip:While both validator and tracking (or stock) rippled servers can be configured to use history shard stores, Ripple recommends adding history sharding only for non-validator rippled servers to reduce overhead for validators. If you run a validator and want to manage ledger history using sharding, run a separate rippled server with sharding enabled.
For more information, reference the [shard_db] example in the rippled.cfg configuration example.
Sizing the Shard Store
Determining a suitable size for the shard store involves careful consideration. You should consider the following when deciding what size your shard store should be:
Although redundant, it is possible to hold full ledger history in the ledger store and the history shard store.
An effective configuration might limit the ledger store only to recent history.
The ledger store history size should at minimum be twice the ledgers per shard, due to the fact that the current shard may be chosen to be stored and it would be wasteful to reacquire that data.
The time to acquire, number of file handles, and memory cache usage is directly affected by sizing.
Each shard contains 2^14 ledgers (16384).
A shard occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.