-
Notifications
You must be signed in to change notification settings - Fork 1k
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
History pruning takes a very long time #8995
Comments
Is this referring to initial sync time, or time to prune? |
This is because reth does not have a "snapshot sync" method, and executes the entire history by default, whereas geth and NM do snap sync by default iirc. The pruning behavior is more relevant here though |
Fixed by #9312 |
Problem
Sender Recovery pruning goes before Account History, and we don't start pruning the next segment until the previous one is completed. Once Sender Recovery is finished (the chart on the right, you can see that it stops taking a significant time and completes instantly), pruner starts to call Account History pruning (chart on the right, spike in time)
The problem is that while we prune Sender Recovery (but do not prune Account History), Account History tables accumulate data and it starts to take more time to prune them after Sender Recovery is done.
Solution
The text was updated successfully, but these errors were encountered: