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.
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
CBG-3854: Integration of the skipped sequence slice into the cache #6789
CBG-3854: Integration of the skipped sequence slice into the cache #6789
Changes from 2 commits
a9d5c48
d33333e
021f14f
cf36b3a
a79f17d
51baa32
bc9a2c4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This feels like the wrong place for this check - we'd want to do it (once) when CacheSkippedSeqMaxWait is set, instead of every time we trigger Clean. Did you have a test scenario that required this check?
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.
Upon reading this again I don't think its needed. If we end up with a customer setting that low of an interval it will just compact pretty much all entries as the maxWait will be 0. I don't think that is too much different to today if the customer was to set that setting that low.
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.
It feels like c.skippedSeqs should keep track of the current value of NumCurrentSeqsSkipped internally, instead of having the changeCache try to keep track of it. 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.
Have added this and the cumulative value to the skipped sequence struct to be tracked there. I have had to make the NumCurrentSeqsSkipped value on skipped sequences struct an atomic value though due to the concurrency around sequences being added/removed from the skipped list and the background task CleanSkippedSequenceQueue running. I was on fence about having it be an atomic value handled inside the skipped sequence slice code, then have that written to the stat in
updateStats()
or just having the value written direct inside the change cache each time a sequence is added/removed? On one hand it feels tidier and better to handle it in skipped sequence code (like the current state of the PR) but it feels like we're adding an extra atomic operation to update the stat of this value.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.
Looking at this with slightly fresher eyes after our meetings, I think I have solution to avoid the race between
updateStats()
and the skipped sequence code writing to them. I will push up the changes now and let me know what 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.
Updating four stats every time we PushSkipped feels like potentially a lot of overhead since they are all atomic writes. This is particularly true for SkippedSeqCap which we expect to change infrequently, but even for the others I don't know if we need this kind of granularity.
One option would be to only update these stats in changeCache.updateStats (which runs once per minute). That would be fine for sgcollect/stats.log - the question is whether we'd expect a customer to want finer granularity than that, and what the performance overhead would be of updating all these in real time.
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.
Completely forgot
changeCache.updateStats
was a thing. Updated to use this!