rebalance rocksdb cache sizes #2557
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
Based on some simple testing done with a few combinations of cache sizes, it seems that the block cache has grown in importance compared to the where we were before changing on-disk format and adding a lot of other point caches. With these settings, there's roughly a 15% performance increase when processing blocks in the 18M range over the status quo while memory usage decreases by more than 1gb! Only a few values were tested so there's certainly more to do here but this change sets up a better baseline for any future optimizations. In particular, since the initial defaults were chosen root vertex id:s were introduced as key prefixes meaning that storage for each account will be grouped together and thus it becomes more likely that a block loaded from disk will be hit multiple times - this seems to give the block cache an edge over the row cache, specially when traversing the storage trie.
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.
Based on some simple testing done with a few combinations of cache sizes, it seems that the block cache has grown in importance compared to the where we were before changing on-disk format and adding a lot of other point caches.
With these settings, there's roughly a 15% performance increase when processing blocks in the 18M range over the status quo while memory usage decreases by more than 1gb!
Only a few values were tested so there's certainly more to do here but this change sets up a better baseline for any future optimizations.
In particular, since the initial defaults were chosen root vertex id:s were introduced as key prefixes meaning that storage for each account will be grouped together and thus it becomes more likely that a block loaded from disk will be hit multiple times - this seems to give the block cache an edge over the row cache, specially when traversing the storage trie.