mirror of https://github.com/hyperledger/besu
An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tag:
Branch:
Tree:
e7ccb33061
23.4.4-branch
4844-devnet-5b
5561migrate-tests-to-Junit5
CloseServerSocket
TransactionValidatorService
add-peer-dns
besu-for-fleet
bump_web3j
eip-4844-interop
github_ci
main
mega-eof
pectra-devnet-4
pectra-devnet3-block-110500-issue
reduceRetries
release-23.1.x
release-23.10.2
release-23.10.3
release-23.10.x
release-23.4.x
release-23.7.x
release-24.1.1
release-24.1.2
release-24.1.x
release-24.2.0
release-24.3.0-hotfix
release-24.3.2-hotfix
release-24.3.3-hotfix
release-24.4.0
release-24.5.0-rc1
release-24.5.0-rc2
release-24.5.3
release-24.7.0
revert-7203-patch-1
revert-7586-fixCHANGELOGtypo
sally-delete-me-2
sally-delete-me-testing-rules
sonarTour
tag-24.3.2
tessera_as_internal_process
test-dco1
test-dco2
test-dco3
verkle
0.8.0
0.8.0-RC1
0.8.0-RC2
0.8.1
0.8.2
0.8.3
0.8.4
0.8.5
0.9.0
0.9.1
1.0.0
1.0.0-RC1
1.0.1
1.0.2
1.0.3
1.1.0
1.1.0-RC1
1.1.1
1.1.2
1.1.3
1.1.4
1.2.0
1.2.0-RC1
1.2.1
1.2.2
1.2.3
1.2.4
1.3.0
1.3.0-RC1
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.3.9
1.4.0
1.4.0-RC1
1.4.0-RC2
1.4.0-beta1
1.4.0-beta2
1.4.0-beta3
1.4.1
1.4.2
1.4.3
1.4.4
1.4.5
1.4.5-RC1
1.4.5-RC2
1.4.5-RC3
1.4.6
1.4.6-RC1
1.4.6-RC2
1.5.0
1.5.0-RC1
1.5.0-RC2
1.5.0-RC3
1.5.1
1.5.1-RC1
1.5.2
1.5.3
1.5.4
1.5.5
1626082128492
1626086821182
20.10.0
20.10.0-RC1
20.10.0-RC2
20.10.1
20.10.2
20.10.3
20.10.4
21.1.0
21.1.0-RC1
21.1.0-RC2
21.1.1
21.1.2
21.1.3
21.1.4
21.1.5
21.1.6
21.1.7
21.10.0
21.10.0-RC1
21.10.0-RC2
21.10.0-RC3
21.10.0-RC4
21.10.1
21.10.2
21.10.3
21.10.4
21.10.5
21.10.6
21.10.7
21.10.8
21.10.9
21.2.0-RC1
21.7.0
21.7.0-RC1
21.7.0-RC2
21.7.1
21.7.2
21.7.3
21.7.4
22.1.0
22.1.0-RC1
22.1.0-RC2
22.1.0-RC3
22.1.0-RC4
22.1.1
22.1.2
22.1.3
22.10.0
22.10.0-RC1
22.10.0-RC2
22.10.1
22.10.101
22.10.2
22.10.3
22.12.8.1
22.12.8.2
22.12.8.3
22.12.8.4
22.4.0
22.4.0-RC1
22.4.0-RC2
22.4.1
22.4.2
22.4.3
22.4.4
22.7.0
22.7.0-RC1
22.7.0-RC2
22.7.0-RC3
22.7.1
22.7.2
22.7.3
22.7.4
22.7.5
22.7.6
22.7.7
23.1.0
23.1.0-BETA
23.1.0-RC1
23.1.0-RC2
23.1.1
23.1.1-RC1
23.1.100
23.1.2
23.1.3
23.10.0
23.10.1
23.10.2
23.10.3
23.10.3-hotfix
23.4.0
23.4.0-RC1
23.4.1
23.4.2
23.4.3
23.4.4
23.7.0
23.7.1
23.7.2
23.7.3
24.1.0
24.1.1
24.1.2
24.10.0
24.10.0-RC1
24.10.0-RC2
24.2.0
24.2.0-RC1
24.2.0-RC2
24.2.0-RC3
24.2.0-RC4
24.3.0
24.3.0-hotfix
24.3.1
24.3.2
24.3.3
24.4.0
24.4.0-RC1
24.4.0-RC2
24.4.0-RC3
24.5.0
24.5.0-RC1
24.5.1
24.5.2
24.5.2-RC0
24.5.2-RC1
24.5.3
24.5.4
24.6.0
24.6.0-RC1
24.6.0-RC2
24.7.0
24.7.0-RC1
24.7.1
24.7.1-RC1
24.8.0
24.8.0-RC1
24.9.0
24.9.0-RC1
24.9.0-RC2
24.9.1
24.9.1-RC1
GHA-TESTRUN-1
GHA.TESTRUN.1
canary
dev
develop
${ noResults }
Jiri Peinlich
97a3494085
* Fast sync should traverse the world state depth first 1. The pending requests queue in the world state downloader is now a different data structure. We now use a list of priority queues. 2. The node requests now know about the parent request that was responsible for spawning them. 3. When a node has data available and is asked to persist before its children are persisted, the node will not do anything. Instead, it will wait for all its children to persist first and will persist together with the last child. Storing children before parents gives us the following benefits: * We don't need to store pending requests on disk any more. * When restarting download from a new pivot, we do not need to walk and check the whole tree any more. And the following drawbacks: * We now have pending nodes in memory for which we already downloaded data, but we do not store them in the database yet. Overall expectations on performance: We still need to download every single state node at least once, so there is no improvement there. We will save a significant amount of time in case we change pivots. And we save lots of read/writes on filesystem because tasks are not needed to be written to disk any more. We want to avoid having too many pending unsaved nodes in memory, not to run out of it. If we were always handling only one request to our peers at the same time, we would not need to be worried, and we would just use a simple depth first search. Because we batch our requests, we might produce too many pending unprocessed nodes in memory if we are not careful about the order of processing requests. That is where the priority on node request comes from. We want to always process nodes lower in the tree before nodes higher in the tree, and preferably we want to first process children from the same parent so that we can save the current unsaved parent as soon as possible. At the moment, I still left in the code several artefacts that I use for debugging the behaviour. I am planning to get rid of most of these counters, feel free to point them out in the review. There is for instance a weird counter in the NodeDataRequest class that I am using to monitor the total amount of unsaved nodes. In case pending unsaved node count rises too high, there is a warning printed into the logs. At the moment of writing, I would expect the counter to stay below 10 000 generally and not rise above 20 000 nodes. If you saw the number rise to for instance 100 000 that would signify a bug. Similarly, because of the order of processing of the nodes, we do not need to store huge number of requests on the disk any more and the whole list fits comfortably into the memory. Without batching, we would not have more than a thousand requests around waiting. Because of the batching, we can see the number of requests occasionally rises all the way up to 300 000, but usually should be under 200 000. Note that at any time there should not be more pending unsaved blocks than pending requests. Such a situation would be a bug to be reported. Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com> * Addressing review comments Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com> * Fixed failing test Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com> * Improving test coverage Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com> * Addressing review comments Signed-off-by: Jiri Peinlich <jiri.peinlich@gmail.com> |
3 years ago | |
---|---|---|
.. | ||
kvstore | Upgrade to Apache Tuweni 2.0 (#2376) | 3 years ago |
pipeline | Version upgrades for 22Q1 (#3217) | 3 years ago |
tasks | When downloading the world state, persist children before parents (#3202) | 3 years ago |
build.gradle | Adding a spdx license check gradle task (#30) | 5 years ago |