Blockchain synchronisation slow down with progress #147
Comments
|
@karek314 I have encountered the same issue, will look to fix asap. |
|
testing with current development is ok |
|
I have noticed that it's not related strictly to progress. Process randomly slows down and can't recover into normal speed, but actually restarting node fix issue for random time. Edit 1 Edit 2 |
|
Yes it is better but still happening. I think now this is because of overal network load. |
|
Not sure if it helps, but it seemed to load better if I blocked port 8000 during the rebuild and when it gets close to being caught up, I stop the rebuild, open port 8000/tcp again, and have it finish the rebuild |
|
the last version has helped (with the noise reduced over the network), but not solved the issue completely. One possibility would be to load blocks by batch of 1000s. also querying several different clients. |
|
client should be pulling from more than 1 server or at least round robin through a batch of servers, I have noticed that trying to do a full sync from just one server makes the server tired (so to speak) and may come to a crawl. |
|
yes this is already foreseen in the next version. see https://github.com/fix/lisk/commit/574f88df80f4adbe9b6ffe6712399cd09afbad66 |
|
@fix the pull looks good but I think it should have a limit say 1k block then it rechecks and uses a new peer from the good peer pool |
- Fixing error messages in logic/transaction.js. - Blocks#processBlock: Separating block verification and application logic. Checking block and transactions validity before any database write. - Refactoring Blocks#loadBlocksOffset to use new applyBlock(). - Documenting code with comments.
|
In the latest release candidates This is being caused by a memory leak in the 3rd party library z-schema. This should be resolved in the next release candidate |
|
I've found another memory leak in the http request module when processing large response bodies, such as loading blocks. Again, it will be fixed in |
Defining functions on constructor prototype.
Defining transaction schemas on constructor prototype.
- Adding unique ids to schemas. - Moving schemas into separate modules. - Do not create query/body variables from req.body. - Removing duplicate schema validations. - Standardising variable names. - Updating z-schema dependency.
- Controlling flow using async waterfall. - Removing async.whilst count < 30.
Add size check when adding to transactionPool - Closes #146
With latest release of testnet v0.2.3 blockchain synchronisation slow down with progress so after 24h my node can't catch up with network since interval between loading each block is much higher than actual network block time.
At beginning it's as fast as it should i guess.
after not more than 15minutes synchronisation process become very slow, so after 24h my 2 nodes couldn't catch up with network. i think it needs to be fixed soon, before release of mainnet.
It's not networking issue since both nodes are located in different locations. Both have pretty good and stable connection. As i have noticed further synchronisation goes process becomes slower.
The text was updated successfully, but these errors were encountered: