-
Notifications
You must be signed in to change notification settings - Fork 772
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
Parachain Node (9.40) stop importing (both relay/para) after syncing #11
Comments
Probably related to: paritytech/cumulus#2495 |
Would be nice to test again with paritytech/substrate#14067 applied. |
@purestakeoskar did you test the Moonbeam 0.9.40 + cherry-pick I provided you? What are the results ? |
@crystalin Yes, it does behave the same, this is with the cherry-pick, the parachain is still syncing with 0 bytes
|
@skunert can you please take a look? |
@purestakeoskar Can you share more of these latest logs? I am particularly interested in some minutes before the slow syncing starts and after (if you saw it end). |
Sorry for the off topic, but this is only place I found the difference in number of relaychain peers, in the first logs (40 peers) and in the second logs (600 peers). This is something that I saw on my parachain nodes after upgrading to v0.9.40, but I would like to confirm that it is fine and understand why this increase is introduced? |
0.9.40 included changes to how syncing works in Substrate and it was refactored to use the underlying network event system which turned out to be too slow/clogged for many people which caused |
I confirm this is still happening on v0.9.43 version of Moonbeam:
Here are the parameters:
(This is using the relay-chain-rpc-urls) |
I realize now that it happened because the relay node was lagging behind in term of blocks and was still syncing, that is why the parachain was not counting imported blocks as new best :/ |
* Derive clap::ValueEnum under cli feature * Remove duplicate CoinStorageKey * Parse listen_on as PeerId in CLI * Increase the finalization step to 100 when major sync Disk performance on mac M1 is so much faster that the race conditions are still possible with 10 blocks, 100 blocks is fine now. * Update README.md
Is there an existing issue?
Experiencing problems? Have you tried our Stack Exchange first?
Description of bug
I've run a moonbeam node using 9.40 (and paritydb).
Restarting it after some hours, I get the node to resync again but still importing blocks after the sync is done:
Steps to reproduce
No response
The text was updated successfully, but these errors were encountered: