Other topics mentioned in this tutorial include graphical user interface (GUI) programming, threading, and asynchronous (async) code in Python.
+
In addition to the above features, you'll also learn a little bit about graphical user interface (GUI) programming, threading, and asynchronous (async) code in Python.
Steps
Install Dependencies
This tutorial depends on various programming libraries. Before you get started coding, you should install all of them as follows:
On Windows, you can build apps using either Windows natively or by using the Windows Subsystem for Linux (WSL).
On native Windows, the GUI uses native Windows controls and should run without any dependencies beyond those mentioned above.
+
Caution: As of 2022-02-01, the latest wxPython is not compatible with Python 3.10 on Windows. You should be able to follow this tutorial if you downgrade to the latest release of Python 3.9.
On WSL, you may need to install libnotify-dev as follows:
The type field in the [node_db] stanza of the rippled.cfg file sets the type of key-value store that rippled uses to hold the ledger store.
-
For almost all purposes, use NuDB. A fast SSD is required. Learn more
-
The RocksDB setting is available for legacy purposes, but is generally not recommended. Learn more
+
This setting does not directly configure RAM settings, but the choice of key-value store has important implications for RAM usage because of the different ways these technologies cache and index data for fast lookup.
+
+
+
For most cases, use NuDB because its performance is constant even with large amounts of data on disk. A fast SSD is required. Learn more
+
+
+
If you are using rotational disks (not recommended) or an unusually slow SSD, use RocksDB. You should avoid this setting for production servers. Learn more
+
+
The example rippled-example.cfg file has the type field in the [node_db] stanza set to NuDB.
More About Using RocksDB
-
RocksDB is a persistent key-value store built into rippled. Support for RocksDB is considered legacy. Servers using RocksDB usually struggle to maintain sync with the Mainnet due to the memory requirements of maintaining a large database. Generally, you should use NuDB instead.
-
Cases where you might use RocksDB include if you need to load historical data saved in RocksDB format, or if you are storing data on slow SSDs or rotational disks. While rotational disks won't be able to keep up with Mainnet, you can probably run offline tests or small private networks on them.
-
RocksDB has performance-related configuration options that you can tweak for more transaction processing throughput. Here is an example [node_db] configuration for RocksDB:
+
RocksDB is an persistent key-value store built into rippled.
+
Caution: As of late 2021, the total size of the ledger has grown large enough that servers using RocksDB often struggle to maintain sync with the Mainnet. Large amounts of RAM can help, but you should generally use NuDB instead.
+
RocksDB is intended to work on either solid-state disks or rotational disks. It requires approximately one-third less disk storage than NuDB and provides better I/O latency. However, the better I/O latency comes as result of the large amount of RAM RocksDB requires to store data indexes.
+
RocksDB has performance-related configuration options that you can tweak for more transaction processing throughput. Here is a recommended [node_db] configuration for RocksDB:
(Adjust the path to the directory where you want to keep the ledger store on disk. Adjust the online_delete and advisory_delete settings as desired for your configuration.)
-
More About Using NuDB
+
More About Using NuDb
NuDB is an append-only key-value store that is optimized for SSD drives.
-
NuDB has nearly constant performance and memory footprints regardless of the amount of data being stored. NuDB requires a solid-state drive. Scalability testing has shown that NuDB has equivalent or better performance than RocksDB in production and comparable configurations.
-
Production servers should be configured to use NuDB and to store the amount of historical data required for your use case.
+
NuDB has nearly constant performance and memory footprints regardless of the amount of data being stored. NuDB requires a solid-state drive, but uses much less RAM than RocksDB to access a large database.
+
Production servers should be configured to use NuDB and to store the amount of historical data required for the use case.
NuDB does not have performance-related configuration options available in rippled.cfg. Here is the recommended [node_db] configuration for a rippled server using NuDB:
Adjust the path to the directory where you want to keep the ledger store on disk. Adjust the online_delete and advisory_delete settings as desired for your configuration. For more details about these settings, see Configure Online Deletion and Configure Advisory Deletion.
+
(Adjust the path to the directory where you want to keep the ledger store on disk. Adjust the online_delete and advisory_delete settings as desired for your configuration.)
Log Level
The example rippled-example.cfg file sets the logging verbosity to warning in the [rpc_startup] stanza. This setting greatly reduces disk space and I/O requirements over more verbose logging. However, more verbose logging provides increased visibility for troubleshooting.
Caution: If you omit the log_level command from the [rpc_startup] stanza, the server writes logs to disk at the debug level and outputs warning level logs to the console. Logging at the debug level requires several more GB of disk space per day than warning level, depending on transaction volumes and client activity.
The [node_db] stanza controls the server's ledger store, which holds ledger history. The amount of disk space you need depends on how much history you plan to keep available locally. An XRP Ledger server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally. Configure the path of the [node_db] to point to your chosen storage location for the ledger store.
You can control how much data you keep with online deletion; the default config file has the server keep the latest 2000 ledger versions. Without online deletion, the server's disk requirements grow without bounds.
-
The following table approximates the requirements for different amounts of history, at the time of writing (2023-07-19):
+
The following table approximates the requirements for different amounts of history, at the time of writing (2018-12-13):
In its default configuration, the rippled server automatically deletes outdated history of XRP Ledger state and transactions as new ledger versions become available. This is enough for most servers, which do not need older history to know the current state and process transactions. However, it can be useful for the network if some servers provide as much history of the XRP Ledger as possible.
Warnings
-
Storing full history is expensive. As of 2023-07-19, the full history of the XRP Ledger occupies approximately 26 terabytes of disk space, which must be entirely stored on fast solid state disk drives for proper server performance. Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day.
-
Additionally, storing full history in NuDB requires single files that are larger than the 16 TB limit of ext4 filesystems, which is the default on many Linux distributions. You must use a filesystem with a larger single-file limit, such as XFS (recommended) or ZFS.
+
Storing full history is expensive. As of 2020-11-10, the full history of the XRP Ledger occupies approximately 14 terabytes of disk space, which must be entirely stored on fast solid state disk drives for proper server performance. Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day.
Acquiring full history from the peer-to-peer network takes a long time (several months) and requires that your server has enough system and network resources to acquire older history while keeping up with new ledger progress. To get a faster start on acquiring ledger history, you may want to find another server operator who has a large amount of history already downloaded, who can give you a database dump or at least allow your server to explicitly peer with theirs for a long time to acquire history. The server can load ledger history from a file and verify the integrity of the historical ledgers it imports.
You do not need a full history server to participate in the network, validate transactions, or know the current state of the network. Full history is only useful for knowing the outcome of transactions that occurred in the past, or the state of the ledger at a given time in the past. To get such information, you must rely on other servers having the history you need.
If you want to contribute to storing the history of the XRP Ledger network without storing the full history, you can configure history sharding to store randomly-selected chunks of ledger history instead.