Proposed 1.8.4 #4061
Merged
Proposed 1.8.4 #4061
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1) Don't acquire so many nodes per pass. It's likely far more than we need. 2) Right-size the finishedReads_ vector on passes other than just the first.
- Only duplicate records from archive to writable during online_delete. - Log duration of nodestore reads. - Include nodestore counters in perf_log output. - Remove gratuitous nodestore activity counting. - Report initial sync duration in server_info and perfLog. - Report state_accounting in perfLog. - Make state_accounting durations more accurate. - Parallel ledger loader. - Config parameter to load ledgers on start.
The nodestore includes a built-in cache to reduce the disk I/O
load but, by default, this cache was not initialized unless it
was explicitly configured by the server operator.
This commit introduces sensible defaults based on the server's
configured node size.
It remains possible to completely disable the cache if desired
by explicitly configuring it the cache size and age parameters
to 0:
[node_db]
...
cache_size = 0
cache_age = 0
intelliot
approved these changes
Jan 11, 2022
RELEASENOTES.md
Outdated
|
|
||
| ### Bug Fixes | ||
|
|
||
| - **Parallel ledger loader & I/O performance improvements**: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, `rippled` needs to be running a high IOPS machine and operators need to explicitly enable this by adding the following to their config file, under the `[node_db]` stanza: |
There was a problem hiding this comment.
Suggested change
| - **Parallel ledger loader & I/O performance improvements**: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, `rippled` needs to be running a high IOPS machine and operators need to explicitly enable this by adding the following to their config file, under the `[node_db]` stanza: | |
| - **Parallel ledger loader & I/O performance improvements**: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, `rippled` needs to be using storage with high IOPS and operators need to explicitly enable the behavior by adding the following to their config file, under the `[node_db]` stanza: |
There was a problem hiding this comment.
I didn't mean to commit I'm going home to my computer it's been a long day! I know I was supposed to do that!😩
| - **Parallel ledger loader & I/O performance improvements**: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, `rippled` needs to be running a high IOPS machine and operators need to explicitly enable this by adding the following to their config file, under the `[node_db]` stanza: | ||
|
|
||
| [node_db] | ||
| ... |
There was a problem hiding this comment.
Suggested change
| ... | |
| # ... |
Just makes it clear that the ... is an ellipsis and should not be added to the config file literally
| JSS(issuer); // in: RipplePathFind, Subscribe, | ||
| // Unsubscribe, BookOffers | ||
| // out: STPathSet, STAmount | ||
| JSS(initial_sync_duration_us); |
There was a problem hiding this comment.
Do we have a PR for adding this to the docs (xrpl.org)?
scottschurr
suggested changes
Jan 11, 2022
This commit corrects a technical flaw that was introduced with commit 7c12f01: as written, a mutex that is intended to help provide synchronization for multiple threads as they are each walking the map, is declared so that each thread is passed a dangling reference to a unique mutex. This commit hoists the mutex outside the thread creation loop, so all threads use a single mutex and eliminating the dangling reference.
Closed
intelliot
reviewed
Jan 13, 2022
| ### Bug Fixes | ||
| - **Adjust mutex scope in `walkMapParallel`**: This commit corrects a technical flaw introduced with commit 7c12f0135897361398917ad2c8cda888249d42ae that would result in undefined behavior if the server operator configured their server to use the 'fast loading' mechanism introduced with 1.8.3. | ||
|
|
||
| - **Adjust pathfinding configuration defaults**: This commit adjusts the default configuration of the pathfinding engine, to account for the size of the XRP Ledger mainnet. Unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous releases. |
There was a problem hiding this comment.
Suggested change
| - **Adjust pathfinding configuration defaults**: This commit adjusts the default configuration of the pathfinding engine, to account for the size of the XRP Ledger mainnet. Unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous releases. | |
| - **Adjust pathfinding configuration defaults**: This commit adjusts the default configuration of the pathfinding engine, to account for the increasing size of the XRP Ledger Mainnet ledger. Unless explicitly overridden, the changes mean that pathfinding operations will generally return fewer and shallower paths than previous releases. |
On the official docs (XRPL.org), Mainnet is capitalized
| This release implements changes that improve the syncing performance of peers on the network, adds countermeasures to several routines involving LZ4 to defend against CVE-2021-3520, corrects a minor technical flaw that would result in the server not using a cache for nodestore operations, and adjusts tunable values to optimize disk I/O. | ||
|
|
||
| ### Summary of Issues | ||
| Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restartiningg. This is one of several releases which will be made to improve on this issue. |
There was a problem hiding this comment.
Suggested change
| Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restartiningg. This is one of several releases which will be made to improve on this issue. | |
| Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restarting. This is one of several releases which will be made to improve on this issue. |
The pathfinding engine built into the code has several configurable parameters to adjust the depth of the paths indexed and explored. These parameters can dramatically impact the performance and memory consumption of a server; higher values can result in resource usage increasing exponentially. These default values were decided early and somewhat arbitrarily at a time when the network and the size of the network state were much smaller. This commit adjusts the default values to reduce the depth of paths to more reasonable levels; unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous versions of the software.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the proposed 1.8.4 release of
rippled, the reference implementation of the XRP Ledger protocol.This release implements changes that improve the syncing performance of peers on the network, adds countermeasures to several routines involving LZ4 to defend against CVE-2021-3520, corrects a minor technical flaw that would result in the server not using a cache for nodestore operations, and adjusts tunable values to optimize disk I/O.