Reduce prune memory usage#4354
Merged
MichaelEischer merged 6 commits intorestic:masterfrom May 24, 2024
Merged
Conversation
This was referenced Jun 5, 2023
36ef4d2 to
9ce9717
Compare
95d2381 to
017e69b
Compare
Member
Author
|
Compared to restic 0.16.4, this PR + #4812 drastically reduce the prune memory usage (using numbers from gcvis, which are slightly lower than those shown by htop, but still appear to be reasonable): Before (restic 0.16.4): After (this PR + #4812): (The repository has 400GB with 8 million blobs. The repack phase differs as the previous prune run already removed a bit of data) This PR optimizes the "search used blobs"-phase, whereas #4812 optimizes the "rebuild index"-phase. |
a3d31f3 to
042cf17
Compare
042cf17 to
ae5e739
Compare
use the same index size for compressed and uncompressed indexes. Otherwise, decoding the index of a compressed repository requires significantly more memory.
ae5e739 to
436afbf
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What does this PR change? What problem does it solve?
The main memory usage of prune (besides the repository index) is a huge CountedBlobSet. The blob ids stored in this set are already stored in the repository index. This PR contains a proof of concept for a data structure that no longer duplicates these ids, but rather reuses them.
This PR fundamentally depends on #4352, which stores all indexEntries in a large array. Thus an indexEntry and its contained blob id becomes identifiable by its array index. As an indexMap can only add but not remove entries, this array index is guaranteed to be stable. Thus the AssociatedData structure in the PR can allocate an array that only consists of the values that were stored in a CountedBlobSet and use the array index to look up the matching blob id in the indexMap.
Using this PR,
prunerequires up to 50% less memory while determining which blobs to keep.Was the change previously discussed in an issue or on the forum?
Alternative to the minimal perfect hashes discussed in #3328
Checklist
[ ] I have added documentation for relevant changes (in the manual).changelog/unreleased/that describes the changes for our users (see template).gofmton the code in all commits.