feat(pruner): respect batch size per run #4246
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
... and 13 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
8d90ebb
to
d838d1c
Compare
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
d838d1c
to
adffcf6
Compare
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
2 times, most recently
from
c26026c
to
128a293
Compare
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
128a293
to
54a67f6
Compare
shekhirin
requested review from
rkrasiuk,
mattsse,
Rjected,
rakita,
joshieDo,
onbjerg and
gakonst
as code owners
joshieDo
reviewed
Aug 18, 2023
| /// Returns number of rows pruned. | ||
| pub fn prune_table_with_range_in_batches<T: Table>( | ||
| /// Returns number of total unique keys and total rows pruned pruned. | ||
| pub fn prune_table_with_range<T: Table>( |
There was a problem hiding this comment.
nit: doc what the bool represents
joshieDo
approved these changes
Aug 18, 2023
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
a560441
to
4939ab9
Compare
This reverts commit df14e1e.
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
45d801b
to
bedb5a4
Compare
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
6511021
to
1ac798b
Compare
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
bdf64ed
to
b941ed4
Compare
shekhirin
commented
Aug 23, 2023
| let prune_mode_block = self | ||
| .modes | ||
| .contract_logs_filter | ||
| .lowest_block_with_distance(tip_block_number, pruned_block)? | ||
| .lowest_block_with_distance(tip_block_number, initial_last_pruned_block)? |
There was a problem hiding this comment.
is it correct? shouldn't it be last_pruned_block?
There was a problem hiding this comment.
this should be correct, this argument works as a lower bound.
if we set it to last_pruned_block something of the kind would happen:
example:
(distance(200), addrA)- contract log pruner goes until distance(128).
last_pruned_blockwould be the block from distance(128)
Which would mean that we'd never go through the blocks between distance(200) -> distance(128) for the tip of this particular run. However, for future runs with higher tips, they should get checked and cleaned-up
shekhirin
force-pushed
the
alexey/pruner-batch-size
branch
from
d4dcc1f
to
407bdcc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Previously batches inside the pruner were only used to print the progress, but the pruning itself was done in one go: one large MDBX transaction that deleted the data in tables according to the provided pruning modes.
This approach had one big downside: MDBX can't do a good job of deleting large chunks of data. This is due to how MDBX deletions work: pages previously occupied by the data aren't just deleted but instead placed inside a "freelist" data structure, which consequent data insertions use to minimize the allocations of new pages. The problem arises when we delete a lot of data in one go: the freelist grows too much, and to insert e.g. a new large entry into
Transactionstable, the MDBX needs to scan the freelist for overflow pages first. It might take a lot of time, and we noticed it with Optimism transactions that took 30 overflow pages to insert.Solution
Delete only small portions of data in one pruner run, allowing the data from new blocks to fill the gaps in database to prevent the freelist from growing too much and causing the aforementioned issue. It works by re-using the
BatchSizesstruct, but instead using it to limit the amount of rows to delete per prune part.It means that:
TxSenderstable (which is the only table that's populated during the pipeline sync even if the prune mode says to prune it) up to the specified block, the pruner will need to run a certain amount of times, allowing the live sync to insert new data between pruner runs. If we run the pruner every 5 blocks, prune 1000 transaction senders per run and have 2 billion transaction senders to prune, it will take2_000_000_000 transaction senders / 1000 transaction senders per run = 2_000_000 pruner runsand2_000_000 pruner runs / (5 blocks * 12 seconds) = 9.2 hours.