-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
perf: Clear cacheKV RAM if its too large #15767
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -93,6 +93,28 @@ func (store *Store) Delete(key []byte) { | |
store.setCacheValue(key, nil, true) | ||
} | ||
|
||
func (store *Store) resetCaches() { | ||
if len(store.cache) > 100_000 { | ||
// Cache is too large. We likely did something linear time | ||
ValarDragon marked this conversation as resolved.
Show resolved
Hide resolved
|
||
// (e.g. Epoch block, Genesis block, etc). Free the old caches from memory, and let them get re-allocated. | ||
// TODO: In a future CacheKV redesign, such linear workloads should get into a different cache instantiation. | ||
// 100_000 is arbitrarily chosen as it solved Osmosis' InitGenesis RAM problem. | ||
store.cache = make(map[string]*cValue) | ||
store.unsortedCache = make(map[string]struct{}) | ||
} else { | ||
// Clear the cache using the map clearing idiom | ||
// and not allocating fresh objects. | ||
// Please see https://bencher.orijtech.com/perfclinic/mapclearing/ | ||
for key := range store.cache { | ||
delete(store.cache, key) | ||
} | ||
Comment on lines
+108
to
+110
Check warning Code scanning / CodeQL Iteration over map
Iteration over map may be a possible source of non-determinism
|
||
for key := range store.unsortedCache { | ||
delete(store.unsortedCache, key) | ||
} | ||
Comment on lines
+111
to
+113
Check warning Code scanning / CodeQL Iteration over map
Iteration over map may be a possible source of non-determinism
|
||
} | ||
store.sortedCache = internal.NewBTree() | ||
} | ||
|
||
// Implements Cachetypes.KVStore. | ||
func (store *Store) Write() { | ||
store.mtx.Lock() | ||
|
@@ -103,44 +125,40 @@ func (store *Store) Write() { | |
return | ||
} | ||
|
||
type cEntry struct { | ||
key string | ||
val *cValue | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How about
to shave off a field from each cache key? |
||
} | ||
|
||
// We need a copy of all of the keys. | ||
// Not the best, but probably not a bottleneck depending. | ||
keys := make([]string, 0, len(store.cache)) | ||
// Not the best. To reduce RAM pressure, we copy the values as well | ||
// and clear out the old caches right after the copy. | ||
sortedCache := make([]cEntry, 0, len(store.cache)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just an observation -- I assume this slice is often oversized, as it ideally match the number of dirty entries in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In general, the entire CacheKV store should just be rewritten entirely. We perenially run into performance issues due to some wack part of its design. Its very overly complicated, for little reason |
||
|
||
for key, dbValue := range store.cache { | ||
if dbValue.dirty { | ||
keys = append(keys, key) | ||
sortedCache = append(sortedCache, cEntry{key, dbValue}) | ||
} | ||
} | ||
|
||
sort.Strings(keys) | ||
store.resetCaches() | ||
sort.Slice(sortedCache, func(i, j int) bool { | ||
return sortedCache[i].key < sortedCache[j].key | ||
}) | ||
|
||
// TODO: Consider allowing usage of Batch, which would allow the write to | ||
// at least happen atomically. | ||
for _, key := range keys { | ||
for _, obj := range sortedCache { | ||
// We use []byte(key) instead of conv.UnsafeStrToBytes because we cannot | ||
// be sure if the underlying store might do a save with the byteslice or | ||
// not. Once we get confirmation that .Delete is guaranteed not to | ||
// save the byteslice, then we can assume only a read-only copy is sufficient. | ||
cacheValue := store.cache[key] | ||
if cacheValue.value != nil { | ||
if obj.val.value != nil { | ||
// It already exists in the parent, hence update it. | ||
store.parent.Set([]byte(key), cacheValue.value) | ||
store.parent.Set([]byte(obj.key), obj.val.value) | ||
} else { | ||
store.parent.Delete([]byte(key)) | ||
store.parent.Delete([]byte(obj.key)) | ||
} | ||
} | ||
|
||
// Clear the cache using the map clearing idiom | ||
// and not allocating fresh objects. | ||
// Please see https://bencher.orijtech.com/perfclinic/mapclearing/ | ||
for key := range store.cache { | ||
delete(store.cache, key) | ||
} | ||
for key := range store.unsortedCache { | ||
delete(store.unsortedCache, key) | ||
} | ||
store.sortedCache = internal.NewBTree() | ||
tac0turtle marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
// CacheWrap implements CacheWrapper. | ||
|
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.
In light of #15767 (comment) consider making this branch unconditional, that is, never use the cache clearing idiom.
The clearing was introduced as part of dbb9923, so I wonder how much performance is gained by the clearing itself. If not much, that's another reason to stop clearing.