-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IA.v3] Update miscellaneous out-of-date stuff #2012
Conversation
mDuo13
commented
Jul 19, 2023
- Fix a typo and remove an obsolete note from the Build a Desktop Wallet Using Python tutorial
- Update Capacity Planning to make it clearer RocksDB is legacy and NuDB is recommended for all situations
- Update Capacity Planning and Configure Full History pages with more recent size estimate for full history
Link check report. 520207 links checked. Preview: https://XRPLF.github.io/xrpl-dev-portal/pr-preview/iav3_edits/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of what I wrote duplicates what's already proposed, so feel free to edit accordingly.
[RocksDB](https://rocksdb.org/docs/getting-started.html) 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](https://rocksdb.org/docs/getting-started.html) is an persistent key-value store built into `rippled`. **Support for RocksDB is considered legacy.** Servers using RocksDB usually struggle to maintain sync with the Mainnet. Generally, you should use NuDB instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of "usually struggle":
Servers using RocksDB tend struggle to maintain sync with the Mainnet as database size increases. A few hundred GB seem to be the upper limit of stability, but this is dependent on memory size. NuDB, on the other hand, uses a relatively stable amount of system memory regardless of database size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rephrased the sentence slightly to add the idea that memory requirements for a large database are the reason for RocksDB struggling.
Link check report. 520207 links checked. Preview: https://XRPLF.github.io/xrpl-dev-portal/pr-preview/iav3_edits/ |
Link check report. 531202 links checked. Preview: https://XRPLF.github.io/xrpl-dev-portal/pr-preview/iav3_edits/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor suggestion and a couple typos. Otherwise looks good to me.
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. | ||
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 involves storing single files that are larger than the 16 TB limit on the ext4 filesystem which is the default on many Linux distributions. To store full history, you must use a filesystem with a larger single-file limit, such as XFS or ZFS. (XFS is recommended.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, storing full history in NuDB involves storing single files that are larger than the 16 TB limit on the ext4 filesystem which is the default on many Linux distributions. To store full history, you must use a filesystem with a larger single-file limit, such as XFS or ZFS. (XFS is recommended.) | |
Additionally, storing full history in NuDB requires single files that exceed the 16 TB on 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. |
content/infrastructure/rippled/installation/capacity-planning.md
Outdated
Show resolved
Hide resolved
content/infrastructure/rippled/installation/capacity-planning.md
Outdated
Show resolved
Hide resolved
Co-authored-by: oeggert <[email protected]>
Link check report. 531202 links checked. Preview: https://XRPLF.github.io/xrpl-dev-portal/pr-preview/iav3_edits/ |
1 similar comment
Link check report. 531202 links checked. Preview: https://XRPLF.github.io/xrpl-dev-portal/pr-preview/iav3_edits/ |