chore: add dynamic stash buckets #5258
Open
+129
−56
Conversation
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
romange
force-pushed
the
Pr5
branch
9 times, most recently
from
d75f1be to
f1e47d4
Compare
|
hmm, this absolutely does not help - I loaded a dataset and its capacity was actually (negligibly) larger with this PR while I would expect to see the reduction in the capacity. BeforeAfter |
Before: our Dash segments contained both regular and stash buckets. Each segment was allocated in one shot. The the segment parameters was carefully chosen to be "allocator friendly" so that segment size was very close to what mimalloc actually allocates a block with size close to the segment size. This indeed has a good memory locality. However when a segment is split, the occupancy rate of two new segments drops to 47-50% which causes memory spikes for small value workloads. This change alters the structure of the segment. Now its stash buckets will be allocated separately and lazily when an item can not be inserted into its home buckets. When a segment is split, its stash buckets will be most likely deallocated. So for example, a 56+4 bucket segment will be split into two 56 bucket segments, so the occupancy rate of each one of them will at ~53.5% percent. Moreover, we will be able to use more stash buckets in the future to be able reach near 100% occupancy rate because now the stash bucket count can be chosen separately without affecting the block size of the "stripped" segment. Signed-off-by: Roman Gershman <roman@dragonflydb.io>
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.
Before: our Dash segments contained both regular and stash buckets. Each segment was allocated in one shot.
The the segment parameters was carefully chosen to be "allocator friendly" so that segment size was very close to what mimalloc actually allocates a block with size close to the segment size. This indeed has a good memory locality.
However when a segment is split, the occupancy rate of two new segments drops to 47-50% which causes memory spikes for small value workloads.
This change alters the structure of the segment. Now its stash buckets will be allocated separately and lazily when an item can not be inserted into its home buckets. When a segment is split, its stash buckets will be most likely deallocated. So for example, a 56+4 bucket segment will be split into two 56 bucket segments, so the occupancy rate of each one of them will at ~53.5% percent. Moreover, we will be able to use more stash buckets in the future to be able reach near 100% occupancy rate because now the stash bucket count can be chosen separately without affecting the block size of the "stripped" segment.