Change expectedSymbols to 2048#7398
Merged
SungJin1212 merged 4 commits intoApr 7, 2026
Merged
Conversation
Signed-off-by: SungJin1212 <tjdwls1201@gmail.com>
CharlieTLe
approved these changes
Apr 6, 2026
Member
CharlieTLe
left a comment
There was a problem hiding this comment.
Thanks, I wonder why it was set to 20 initially.
friedrichg
reviewed
Apr 6, 2026
| # Changelog | ||
|
|
||
| ## master / unreleased | ||
| * [CHANGE] Distributor: Increase the default capacity of `expectedSymbols` from 20 to 2048 in the PRW2 path to reduce slice reallocations. #7397 |
Member
There was a problem hiding this comment.
Suggested change
| * [CHANGE] Distributor: Increase the default capacity of `expectedSymbols` from 20 to 2048 in the PRW2 path to reduce slice reallocations. #7397 | |
| * [CHANGE] Distributor: Increase the default capacity of `expectedSymbols` from 20 to 2048 in the PRW2 path to reduce slice reallocations. #7398 |
|
|
||
| var ( | ||
| expectedSymbols = 20 | ||
| expectedSymbols = 2048 |
Member
There was a problem hiding this comment.
Ultimately, this is about labels. if your requests have more labels, you will need this.
what do you think about something like this?
var symbolsHighWaterMark atomic.Int64
func init() {
symbolsHighWaterMark.Store(int64(expectedSymbols))
}
func ReuseWriteRequestV2(req *PreallocWriteRequestV2) {
// Update high watermark, capped to prevent outliers from inflating all allocations.
if n := int64(cap(req.Symbols)); n > symbolsHighWaterMark.Load() && n <= 8192 {
symbolsHighWaterMark.Store(n)
}
// ... existing cleanup code ...
}
writeRequestPoolV2 = sync.Pool{
New: func() any {
return &PreallocWriteRequestV2{
WriteRequestV2: WriteRequestV2{
Symbols: make([]string, 0, symbolsHighWaterMark.Load()),
},
}
},
}
Starts at expectedSymbols (20), grows to match real usage, caps at 8192 (128KB per pooled object) to prevent runaway allocation from outlier requests.
Member
Author
There was a problem hiding this comment.
Sound goods, I introduced an adaptive way. Can you take a look?
I think the initial 20 is small, so set it to 128.
Signed-off-by: SungJin1212 <tjdwls1201@gmail.com>
Signed-off-by: SungJin1212 <tjdwls1201@gmail.com>
Member
Author
|
@CharlieTLe |
Signed-off-by: SungJin1212 <tjdwls1201@gmail.com>
friedrichg
added a commit
that referenced
this pull request
Apr 9, 2026
The existing benchmark compared dynamic EMA against fixed-128 with unequal cleanup: the dynamic path called full ReuseWriteRequestV2 (Source reset, Timeseries handling, EMA update) while the fixed path only cleared Symbols. This biased timing in favor of the fixed path. Changes: - Equalize cleanup in fixed_capacity to match ReuseWriteRequestV2 (minus the EMA update) - Add fixed_capacity_2048 sub-benchmark to compare against the original #7398 proposal, answering whether EMA complexity is justified over a well-tuned static value Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Friedrich Gonzalez <1517449+friedrichg@users.noreply.github.com>
friedrichg
added a commit
that referenced
this pull request
Apr 9, 2026
The existing benchmark compared dynamic EMA against fixed-128 with unequal cleanup: the dynamic path called full ReuseWriteRequestV2 (Source reset, Timeseries handling, EMA update) while the fixed path only cleared Symbols. This biased timing in favor of the fixed path. Changes: - Equalize cleanup in fixed_capacity to match ReuseWriteRequestV2 (minus the EMA update) - Add fixed_capacity_2048 sub-benchmark to compare against the original #7398 proposal, answering whether EMA complexity is justified over a well-tuned static value Signed-off-by: Friedrich Gonzalez <1517449+friedrichg@users.noreply.github.com>
This was referenced Apr 10, 2026
friedrichg
added a commit
that referenced
this pull request
Apr 14, 2026
…ymbol pooling comparison (#7412) * Add a benchmark to compare the fixed symbol with the dynamic Signed-off-by: SungJin1212 <tjdwls1201@gmail.com> * Equalize benchmark cleanup and add fixed_capacity_2048 sub-benchmark The existing benchmark compared dynamic EMA against fixed-128 with unequal cleanup: the dynamic path called full ReuseWriteRequestV2 (Source reset, Timeseries handling, EMA update) while the fixed path only cleared Symbols. This biased timing in favor of the fixed path. Changes: - Equalize cleanup in fixed_capacity to match ReuseWriteRequestV2 (minus the EMA update) - Add fixed_capacity_2048 sub-benchmark to compare against the original #7398 proposal, answering whether EMA complexity is justified over a well-tuned static value Signed-off-by: Friedrich Gonzalez <1517449+friedrichg@users.noreply.github.com> --------- Signed-off-by: SungJin1212 <tjdwls1201@gmail.com> Signed-off-by: Friedrich Gonzalez <1517449+friedrichg@users.noreply.github.com> Co-authored-by: SungJin1212 <tjdwls1201@gmail.com>
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
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.
This PR increases

expectedSymbolsto2048to reduce slice reallocations. The current value of20is very small in the production level.As shown in the attached chart, after applying the change to 2048 (around 19:30), I have observed reduced allocation spikes.
Which issue(s) this PR fixes:
Fixes #
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]