-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix rewrite chunk reuse reference #3710
Conversation
Signed-off-by: yeya24 <[email protected]>
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.
Thanks!
@@ -47,16 +47,17 @@ func (s *lazyPopulateChunkSeriesSet) Next() bool { | |||
continue | |||
} | |||
|
|||
chks := make([]chunks.Meta, len(s.bufChks)) |
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.
Nice, so this is allowing us to not care about locking, but instead allocate more mem, right? 🤗
How benchmarks are looking with this?
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.
Sorry I didn't get the point. How is it related to locking? Did you mean adding a lock to protect s.bufChks
?
I haven't benchmarked this. For a one-off job, memory seems not the highest priority. Maybe we can call GC manually somewhere if the mem usage is too high?
I am not sure if we can fix this without allocating additional memory. What do you think?
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 mean, no lock is needed because we copy the slice?
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.
let's talk offline (:
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.
Sorry but I think I missed something. Is s.bufChks
accessed by multiple goroutines? I thought it is accessed sequentially.
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.
Not yet. 🤣
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.
;p
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.
Let's restart this. Can you explain what problem are you solving? you mentioned in the description that you are fixing some problem, which one? (:
Just creating slices everywhere is not the best idea if we care about efficiency here, we never seen any error around this place on production too.
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 cannot tell tbh. But with this change the relabel pr works. I guess it is the problem of that pr because the rewrite delete works perfect.
But cannot figure out why.
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 cannot tell tbh. But with this change the relabel pr works. I guess it is the problem of that pr because the rewrite delete works perfect.
But cannot figure out why.
Signed-off-by: yeya24 [email protected]
Fix buf chunks reuse reference.
Here
m
is a reference to the buffered chunk, we should use a copy instead.I can reproduce this problem while adding tests for #3707.
Changes
Verification