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
Node can't catch up if stay long enough offline #823
Comments
What version are you experiencing this issue on? |
Mainly every each version but the latest that I tested were 12.1. If my node was also left behind after update the db it would be ok however since this happens just when my node is been offline for while it raise the concern that it may be a serious performance issue (exponencial?); what if the TPS increases? Bootstrap a new node when we have dozens of million of blocks will be possible? |
I wouldn't worry about future theoretical performance. There are much more efficient methods of bootstrapping, but they haven't been implemented yet (they are complicated). Using an alternative to LMDB may also speed things up. Right now though, we're making the existing bootstrapping system work until new ideas are implemented. |
@PlasmaPower Hey, It seems more related to the block verification procedure when Sync, Using an alternative DB may not make big improvement, Please have review the issue #833 , Thank you. |
I have a same issue. I'm running Node version 13.0 (latest one). |
@rotilho Hi Bro, How is your Sync going? Is it finished? |
@ariesunny I gave up. The only way to keep it sync is downloading a updated version of the database and don't keep the node down for too long. |
Is this being addressed or at least acknowledged by someone? I had an up to date node which I shutdown and only turned it on after a couple of months and I just cannot seem to catch up. I already updated to 12.1 but still, it's completely stuck. The block count (~7.7M) + downloaded blocks (~1.2M) seems to add up to more or less what I see in nanode as the amount of blocks. The block count is going up very slowly, at a rate at which it simply won't ever catch up and I do see some CPU usage on the nano node so it's definitely doing something. This is running on an 8 cores i7 @ 2.6hz on a 100mbit/s internet connection on Linux x64. This is what I see in the log file:
The fact that we have to resort to some random data upload website to download the latest state of the ledger to be able to keep up is concerning. Also note that this is not a bootstrap from scratch, this node was up to date until March 23rd. Back then I did a bootstrap from scratch and it only took a few hours to get synced up. Edit: I downloaded the latest dump from here (modified date of today at 12:33am) and after almost 2 hours I'm stuck and the amount of downloaded blocks is going up. How does anyone even keep up with this? |
The need for IO optimizations is a well-known issue. We'll be working on that once other higher priority issues are fixed. |
This should be resolved by a few different on-going projects. Lazy bootstrapping (#995) will reduce the amount of disk I/O and voting traffic during bootstrapping since it will only pull confirmed blocks, thus no need to store them in a different database temporarily or ask for confirmation. Vote-by-hash and vote stapling both ensure less bandwidth is used and vote stapling makes the votes a bit more durable so that nodes can be use them for longer, which reduces network utilization greatly. I am going to close this ticket so that we can track the individual improvements directly but let me know if there are additional questions. |
Currently when I close my node from a old laptop (4 years old i7) the node can't catch up with new blocks getting slowly more out-dated.
If I download a up-to-date database from external source the node is able to keep up with the latest blocks.
Steps to reproduce the issue:
Describe the results you received:
Unprocessed blocks accumulates
Describe the results you expected:
Slowly catch up with the latest blocks
Environment:
The text was updated successfully, but these errors were encountered: