Add experimental x-trie-log subcommand for one-off backlog prune#6188
Add experimental x-trie-log subcommand for one-off backlog prune#6188siladu wants to merge 2 commits intobesu-eth:mainfrom
Conversation
Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
|
besu/src/main/java/org/hyperledger/besu/cli/subcommands/storage/TrieLogHelper.java
Fixed
Show fixed
Hide fixed
Signed-off-by: Simon Dudley <simon.dudley@consensys.net>
|
|
My last run on this with a medium-running node (3.5 months) gave this results: Running total number pruned = real 195m11.516s DB was reduced by 64GB After: |
| rootWorldStateStorage | ||
| .streamTrieLogKeys(limit) | ||
| .map(Bytes32::wrap) | ||
| .map(Hash::wrap) | ||
| .forEach( |
There was a problem hiding this comment.
I am guessing that most users of this subcommand are going to want to prune pretty close to head. Meaning there will be far more trielogs deleted than retained. This implementation is safe, but probably going to be pretty slow in most cases.
IMO we could/should add an alternate implementation that checks that the number of retained trielogs is below a certain reasonable threshold. We copy those trielogs to an alternate column family, truncate the trielog family, and move the trielogs back into the newly truncated CF. That should make this operation markedly faster for what I suspect will be the typical use case (offline pruning a huge number of trielogs)
There was a problem hiding this comment.
to be clear, I would start from the blockchain storage and get the latest 'x' hashes that we want to retain rather than streaming all of the keys in the trielog CF
PR description
Part of #5390
TODO
To install on a node
Usage and examples