CBG-4032: memory based rev cache implementation

[gregns1]

CBG-4032

Implementation of memory bounded rev cache.
Summary of changes:

• Added stats for overall rev cache size in bytes
• This is passed into the rev cache and atomically incremented/decremented as needed
• Added a function on DocumentRev to calculate the document size based on what we agreed to be measured, channels, revisions and body in bytes.
• This is called when adding to rev cache for new docs, and after a load from the bucket
• There is also a version of this for revision deltas
• Added a representation of a documents size in DocumentRevision and rev cache value, for purposes of passing up and down stack.
• Create a config value in RevisionCacheOptions to link up to RevCache code for the overall memory limit to be configured on. Temporarily this way, CBG-4134 will finish this side of the work.
• Left number based eviction where it is. Added a new function for memory based eviction that is called separately after the value is populated with its size + incremented the stat to reflect this.
• Tests covering each operation on rev cache, eviction and delta caching. In addition have some test coverage of loading from the bucket.
• For sharded revision cache memory limit, I have copied what we already fo for the number capacity (see NewShardedLRURevisionCache

Pre-review checklist

• Removed debug logging (fmt.Print, log.Print, ...)
• Logging sensitive data? Make sure it's tagged (e.g. base.UD(docID), base.MD(dbName))
• Updated relevant information in the API specifications (such as endpoint descriptions, schemas, ...) in docs/api

Integration Tests

• GSI=true,xattrs=true https://jenkins.sgwdev.com/job/SyncGateway-Integration/2664/

[adamcfraser]

Overall approach seems ok, a few questions/suggestions.

[adamcfraser]

This is only going to evict a single value, and there's no guarantee that the evicted value is large enough to offset the incoming value - could end up in a situation where 100 20MB documents trigger the eviction of 100 1k documents, and leave the cache significantly above the memory target.

[gregns1]

I'm not sure I follow. This function is to determine if we need eviction based upon if we have a max size set & the current memory count is above the threshold.
If true it will call performEviction() which acquires the lock and runs a loop for eviction till the memory stat is below the threshold.

[adamcfraser]

This was my mistake - misread performEviction as 'if' instead of 'for'.

[adamcfraser]

asDocumentRevision is only intended to copy immutable properties (and so doesn't require callers to hold value.lock.Lock). With the updateDelta handling I don't think itemBytes can be treated as immutable, but it's also important from a performance perspective to not hold the lock.

[adamcfraser]

One option might be to separate the delta and non-delta byte storage on revCacheValue, and compute the sum for DocumentRevision.MemoryBytes here.

[gregns1]

Good spot. I have ended up removing this all together as I can work around this by uisng the getItemBytes() function that acquired read lock to incr/decr the stat wherever necessary.

[adamcfraser]

I still feel like there is a lot of unnecessary locking of itemBytes in the case where delta sync is not being used (and so itemBytes is immutable), but I'm fine coming back to that based on analysis of the perf results.