-
Notifications
You must be signed in to change notification settings - Fork 19.6k
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
core: fix state flushing for catalyst mode #26319
Conversation
Ooohh ouch. It took a while before I grokked what you meant by "fix state flushing", when I looked at the code. tldr: Our mechanism to flush to disk is based on the elapsed block processing time, as measured by blockchain.gcproc. This mechanism won't work well unless we actually make sure to bump gcproc when processing blocks, which is fixed by this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I have a node running with this patch for almost 30 hours and the accumulated processing time since then is 26 minutes. So basically on this machine a state will be persisted for mainnet every 65+ hours. Was this the case also before? INFO [12-07|21:37:48.494] Deciding to flush time=26m13.570042217s limit=1h0m0s lastWrite=0 chosen=16,135,433 |
@s1na Yep. |
The gcproc field tracks the amount of time spent processing blocks, and is used to trigger a state flush to disk when a certain threshold is reached. After the merge, single block insertion by CL is the most common source of block processing time, but this time was not added into gcproc.
The gcproc field tracks the amount of time spent processing blocks, and is used to trigger a state flush to disk when a certain threshold is reached. After the merge, single block insertion by CL is the most common source of block processing time, but this time was not added into gcproc.
This is the simplest solution to increase block processing time for all blocks the CL gives us regardless of whether they end up on the canonical chain or not. Alternatively we can track the execution time of each processed block.