-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Internal transactions fetcher stops indexing after some time #2105
Comments
@APshenkin what is in error log? it may be fat blocks, that cannot be processed in the allotted time. You can try to increase the timeout for indexer depending on your variant or/and to decrease batch_size for internal transactions fetcher Also, if you use geth node I highly recommend using 1.3.15+ release, because of improvements in internal transactions indexer there. |
I use parity archive node. There is nothing special that I can see in logs. BTW after blockscout restarting it continues internal tx sync |
Found something in logs. They may be not in right order, because we send them to kibana from stdout Here are huge logs
|
And issue is still present. After restart Blockscout sync internal transactions and works well but after some time (several hours) it stops syncing internal transactions And after restart there is no any violates foreign key constraint errors (just sync all blocks) |
If you updated existing BS instance with 1.3.13, that was previously partially indexed, it is recommended to run this query against db to fix "bad" blocks: |
@vbaranov ok, will try it. BTW our blockscout is already in sync (we set starting sync only from block 7878000) So at the moment all blocks have synced internal transactions. But during live sync (new generated blocks), syncing internal transactions stops after some time. Then we need to restart blockscout to run syncing again and it sync all blocks that were stucked |
So the issue is still present |
@vbaranov is there any updates? Do you face the same issue? Or maybe we have to upgrade our blockscout version? |
@APshenkin no, we have no exactly your issue. We encounter timed out indexing for some blocks, that have a lot of transactions/internal transactions, but they finally processed later. Basically, what you can do is to manage memory usage, concurrency and batch size for internal txs indexing, as I recommended here #2105 (comment). Also, consider increasing the resources on your database instance. For example, here is the clarification of the size of our RDS instance to support ETH Mainnet #2013 (comment) Upgrade to https://github.com/poanetwork/blockscout/releases/tag/v2.0.0-beta is also recommended to improve performance of the Blockscout pages |
@vbaranov Today I was able to find an exception in logs. Log file is huge, so I pasted it to gist https://gist.github.com/APshenkin/9d71fcf92f4d853bc84d8f88023e95e8 After this exception internal transaction fetching stops |
@vbaranov |
Hey @APshenkin, I think I found the cause of your problem and that #2346 fixes it. Basically there is a temporary fetcher that refetches blocks to check that they have the correct transactions. This problem normally should just disappear on its own, when the blocks and its transactions gets refetched, but I believe that what happens in your case it that it fails so many times that it stops before this can happen. Could you please if possible confirm my suspicion and check that either
|
Hi @pasqu4le I'm not sure that this was the reason of issue, because I faced it before adding Today we updgraded our blockscout to 2.0.1 and now we have a lot of blocks with We will monitor this error after all refetch_needed will be completed |
Hey @APshenkin, thanks for the feedback. The fact that the issue predates Please keep me updated if the problem is still present after no block needs to be refetched anymore and reopen the issue if it gets closed before that. |
@pasqu4le We restarted blockscout at 18 p.m to complete clean test. After 1 hour there are 4 blocks, that have Their numbers are: Also using Here is full app log. Maybe it helps: FYI we launch sync only from block 7878000 and all blocks are sync BTW thank you for help! UPDATED: After blockscout restart these blocks are now synced for internal transactions
|
@APshenkin glad I could help, I'll check out this new error you got and see what I can do |
Hey @APshenkin I have figured out what was the problem with your last error(s) and #2375 should get rid of it. |
Hey @APshenkin if you are referring to the first issue (the one with I'm going to write an fix soon an I'll notify you on this thread when it is available. |
Hi @vbaranov @pasqu4le
|
Hello @royki ! I am facing the same issue, do you have any update on how you manage to fix this ? |
Hi @MaxTeiger , You need to update manually in the From @vbaranov in discord -> https://discord.com/channels/502416149343109121/959785606051954720/960441819655708695
Here are the steps and sql, that I performed
This will return |
Thank you very much ! |
After launching blockscout it starts to sync internal transactions, but after some hours it's stops syncing them. Currently all blocks are in sync in our instance, but internal transactions is stil in progress. With this simple SQL we monitor amount of non-synced internal transactions blocks:
On start up number of blocks decrease, but after several hours it start only increasing (new blocks inserted)
Environment
elixir -version
):Operating System: Alpine Linux v3.9
Blockscout version: 1.3.13
Steps to reproduce
Run blockscout and wait
Expected behaviour
internal transactions sync completes
Actual behaviour
after several hours it stops syncing and amount of non synced blocks increase (new blocks inserted)
The text was updated successfully, but these errors were encountered: