ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 07:35:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Spell checker pass

Browse Source
This commit is contained in:
mDuo13
2021-05-27 16:26:21 -07:00
parent 487a28f4c2
commit 032eee07fb
26 changed files with 197 additions and 163 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/tutorials/manage-the-rippled-server/installation/capacity-planning.md
View File

@@ -184,7 +184,7 @@ Memory requirements are mainly a function of the `node_size` configuration setti
Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use.
During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100 MBit/s network link. Therefore, a gigabit network interface is required for reliable performance.
During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100 megabit/s network link. Therefore, a gigabit network interface is required for reliable performance.
Here are examples of observed uncompressed network bandwidth use for common `rippled` tasks:

2
content/tutorials/manage-the-rippled-server/installation/system-requirements.md
View File

@@ -16,7 +16,7 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
- RAM: 8 GB+
<!-- SPELLING_IGNORE: iops, ntp, x86_64 -->
<!-- SPELLING_IGNORE: iops, ntp, x86_64, ec2 -->
Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A fast network connection is preferable. Any increase in a server's client-handling load increases resources needs.

2
content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-centos-rhel.md
View File

@@ -13,7 +13,7 @@ These instructions assume you have already [installed `rippled` from the `yum` r
To update manually, complete the following steps:
1. If you are upgrading to `rippled` 1.7.0 from an earlier version, re-add the repository to get Ripple's updated GPG key. Otherwise, skip this step:
1. If you are upgrading to `rippled` 1.7.0 from an earlier version, re-add the repository to get Ripple's updated GPG key. Otherwise, skip this step: <!-- SPELLING_IGNORE: gpg -->
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]

1
content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.md
View File

@@ -298,6 +298,7 @@ Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1
## [veto_amendments] section in config file ignored
<!-- SPELLING_IGNORE: veto_amendments -->
Log messages such as the following occur when your `rippled.cfg` file contains a legacy `[veto_amendments]` stanza. The first time the server starts on version 1.7.0 or higher, it reads the stanza to set amendment votes; on later restarts, it ignores the `[amendments]` and `[veto_amendments]` stanzas and prints this message instead.