-
Notifications
You must be signed in to change notification settings - Fork 833
Upgrade Thanos to latest master #3363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
532679a
6184848
bd22e54
b9a51b7
77bbc86
202c725
9cc84b1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've a doubt. In this Thanos upgrade,
bqss.series[bqss.next].Labels
is alabelpb.ZLabel
, which means the whole protobuf message[]byte
will be retained until the query execution completes. Don't we risk to end up utilising more memory than before? In queriers I'm more worried about memory utilisation than memory allocations rate.Thoughts @pstibrany @bwplotka ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand this correctly, problem you're suggesting should not be an issue in querier. Previously querier would receive the message and then extract individual strings (making a copy), and (possibly) discard the message. Now we skip the extraction part at the cost of keeping the message in memory longer. As long as we don't retain these labels somewhere, I think this should decrease memory usage. But it's risky, and we better keep an eye on it.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I think*storepb.Series
already keep reference to entire original message viac.Raw.Data
)Turns out they make a copy. Perhaps this could be improved as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should better investigate / understand how this behave. If a query execution is slow, we may potentially increase the memory utilisation with this PR's change.
I'm going to merge this PR to unblock other work based on this, but let's keep an eye on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned offline. Thanks to ZLabels, it's really up to you. If you don't want to hold memory, just use
labelpb.DeepCopy
function to do copy manually (: But you are right if you hold labels for longer time, it's very likely you want to copy those.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are still experimenting, so you are right. Might be risky