Skip to content
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

eth/protocols/snap: fix batch writer when resuming an aborted sync #27842

Merged
merged 1 commit into from
Aug 3, 2023

Conversation

karalabe
Copy link
Member

@karalabe karalabe commented Aug 3, 2023

Fixes #27813.

The closure caused all subtasks to reference the same one batch when writing, so instead of each subtask of a contract growing and flushing it's own batch, they all grew the last one's, but flushed their own.

Interestingly however, this should only be an issue if there's also a lack of peers, otherwise whenever a delivery into the last batch is made, it should have flushed out everyone else's data too.

Edit: Actually, it might happen that the last chunk finishes earlier than the rest, which will cause memory to keep piling there. This will result in the node growing in memory until the pivot moves and sync restarts. This was confirmed via a bench pair comparing master (yellow) with PR (green):

Screenshot 2023-08-03 at 13 44 55

Additionally, this might also mean that all that extra memory that was piled into the last batch post-last-chunk-completion will actually get lost and the healer will need to redownload it. Waiting for benchmarkers to progress to the heal phase to verify.

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@karalabe
Copy link
Member Author

karalabe commented Aug 3, 2023

Ah, the issue might be that the last batch finishes, and then will never get checked again, whilst the others are still pulling data and piling it into the last batch.

@karalabe karalabe merged commit 6e934f4 into ethereum:master Aug 3, 2023
1 check passed
@karalabe karalabe added this to the 1.12.1 milestone Aug 3, 2023
DarianShawn pushed a commit to dogechain-lab/dbsc that referenced this pull request Sep 4, 2023
### Description

upstream PR:
[go-ethereum#27842](ethereum/go-ethereum#27842)

Fixes ethereum/go-ethereum#27813.

The closure caused all subtasks to reference the same one batch when
writing, so instead of each subtask of a contract growing and flushing
it's own batch, they all grew the last one's, but flushed their own.

Interestingly however, this should only be an issue if there's also a
lack of peers, otherwise whenever a delivery into the last batch is
made, it should have flushed out everyone else's data too.
devopsbo3 pushed a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

panic: pebble: batch too large: >= 4.0 G
2 participants