-
Notifications
You must be signed in to change notification settings - Fork 138
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
Conversation
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.
A few naming nits, but also a question about perf overhead of stats computation per skipped sequence, and whether they should move to changeCache.updateStats.
db/change_cache.go
Outdated
c.db.DbStats.Cache().SkippedSeqLen.Set(int64(len(c.skippedSeqs.list))) | ||
c.db.DbStats.Cache().SkippedSeqCap.Set(int64(cap(c.skippedSeqs.list))) | ||
if err == nil { | ||
c.db.DbStats.Cache().NumCurrentSeqsSkipped.Add(-1) |
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 😄
db/change_cache.go
Outdated
numSequences := newEntry.getNumSequencesInEntry() | ||
c.skippedSeqs.PushSkippedSequenceEntry(newEntry) | ||
c.db.DbStats.Cache().SkippedSeqLen.Set(int64(len(c.skippedSeqs.list))) | ||
c.db.DbStats.Cache().SkippedSeqCap.Set(int64(cap(c.skippedSeqs.list))) |
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!
…em naming. Test updates to reflect stat chnages too.
…ppedSequenceEntry
db/change_cache.go
Outdated
@@ -90,6 +89,10 @@ func (c *changeCache) updateStats(ctx context.Context) { | |||
c.db.DbStats.Cache().PendingSeqLen.Set(int64(c.internalStats.pendingSeqLen)) | |||
c.db.DbStats.CBLReplicationPull().MaxPending.SetIfMax(int64(c.internalStats.maxPending)) | |||
c.db.DbStats.Cache().HighSeqStable.Set(int64(c._getMaxStableCached(ctx))) | |||
c.db.DbStats.Cache().SkippedSeqLen.Set(c.skippedSeqs.getSliceLength()) |
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.
Is there something non-standard going on with the whitespace here? (spaces instead of tab, maybe?)
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 don't think so? I have updated to reflect the changes to have a getStats() call for the skipped slice. I think the spacing in Github could be weird, it looks fine in goland to me.
db/change_cache.go
Outdated
base.InfofCtx(ctx, base.KeyCache, "Starting CleanSkippedSequenceQueue for database %s", base.MD(c.db.Name)) | ||
|
||
maxWait := int64(c.options.CacheSkippedSeqMaxWait.Seconds()) | ||
if maxWait < 1 { |
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.
…6789) * CBG-3854: Integeration of the skipped sequence slice into the cache * remove old chnages not needed anymore + gh actions failures * updates based of review. Move stat update to updateStats and alter soem naming. Test updates to reflect stat chnages too. * remove incorrect incrementing of num current sequences inside PushSkippedSequenceEntry * Fix race condition in updateStats() * updates off review * tidy CleanSkippedSequenceQueue
…6789) * CBG-3854: Integeration of the skipped sequence slice into the cache * remove old chnages not needed anymore + gh actions failures * updates based of review. Move stat update to updateStats and alter soem naming. Test updates to reflect stat chnages too. * remove incorrect incrementing of num current sequences inside PushSkippedSequenceEntry * Fix race condition in updateStats() * updates off review * tidy CleanSkippedSequenceQueue
* CBG-3852: Implementation of single sequence entry for skipped sequence slice (#6747) * CBG-3852: implementation of single sequence entry for skipped sequence slice * minor updates to make setLastSeq no-op for single values * updates for review round * remove not needed comment * updates based off review * CBG-3853: Implementation of range sequence entry for skipped sequence slice (#6764) * CBG-3854: Integration of the skipped sequence slice into the cache (#6789) * CBG-3854: Integeration of the skipped sequence slice into the cache * remove old chnages not needed anymore + gh actions failures * updates based of review. Move stat update to updateStats and alter soem naming. Test updates to reflect stat chnages too. * remove incorrect incrementing of num current sequences inside PushSkippedSequenceEntry * Fix race condition in updateStats() * updates off review * tidy CleanSkippedSequenceQueue * stats update * CBG-3855: Sequence range removal support (#6801) * CBG-3855: support for seqeuence range removal * add comment to function + remove repeated code * refactor error handling, simplify stat calculation update * CBG-3850: Optimise releaseUnusedSequenceRange (#6831) * CBG-3850: Optimise releaseUnusedSequenceRange function + support for ranges in pending queue * updates to add _pushRangeToPending and _removeSubsetOfRangeFromSkipped to process duplicates sequences between unused rnage and pending/skipped lists * fix race condition in test * fix for incorrect logic for removing skipped range * updates based off review * updates to fix incorrect code + add extra test coverage of changes * change error name * CBG-3945: Fix for panic in _clip method on skipped sequence slice (#6842) * fix test to use old api
CBG-3854
Pre-review checklist
fmt.Print
,log.Print
, ...)base.UD(docID)
,base.MD(dbName)
)docs/api
Integration Tests
GSI=true,xattrs=true
https://jenkins.sgwdev.com/job/SyncGateway-Integration/2388/