node: Use TTL for blobovnicza tree cache #875
No reviewers
TrueCloudLab/storage-core-developers
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#875
Loading…
Reference in a new issue
No description provided.
Delete branch "acid-ant/frostfs-node:bugfix/ttl-for-blobz-tree-cache"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Close #866
Signed-off-by: Anton Nikiforov an.nikiforov@yadro.com
Use TTL for blobovnicza tree cacheto blobovnicza: Use TTL for blobovnicza tree cacheblobovnicza: Use TTL for blobovnicza tree cacheto node: Use TTL for blobovnicza tree cache@ -61,6 +61,7 @@ storage:
depth: 1 # max depth of object tree storage in key-value DB
width: 4 # max width of object tree storage in key-value DB
opened_cache_capacity: 50 # maximum number of opened database files
opened_cache_ttl: 20m # ttl for opened database file
20m
used here just to start discussion.I would use smaller value here (
5m
or even1m
). PUT is frequently followed by GET, so we have some time to retain non-active blobovnicza open.In case of heavy random-read and 10 shards each with 10_000 databases and accessing 400 objects per-second we will access each db approximately once per ((10 * 10_000 / 400) = 250 seconds <= 300 seconds = 5 min). Also take in mind that in this scenario they will probably be closed earlier because of the cache capacity, so bigger values are likely to be of no use.
Agree, I've added your comment in doc.
@ -24,2 +26,4 @@
OpenedCacheSizeDefault = 16
// OpenedCacheTTLDefault is a default cache ttl of opened Blobovnicza's.
OpenedCacheTTLDefault = time.Minute * 20
Maybe not close at all by default?
Agree, let's leave current behavior.
@ -28,6 +28,7 @@ storage:
type: blobovnicza
perm: 0600
opened_cache_capacity: 32
opened_cache_ttl: 20m
I would not touch
mainnet
andtestnet
configs at all, they are for public networks, there are much less load there.Reverted changes in these configs.
@ -25,2 +26,2 @@
func newDBCache(size int, dbManager *dbManager) *dbCache {
cache, err := simplelru.NewLRU[string, *sharedDB](size, func(_ string, evictedDB *sharedDB) {
func newDBCache(size int, ttl time.Duration, dbManager *dbManager) *dbCache {
cache := expirable.NewLRU[string, *sharedDB](size, func(_ string, evictedDB *sharedDB) {
I am not sure
expireable.LRU
evicts and not just invalidates entries on access.Have you checked that it has some sort of a timer?
Can we be sure that if get from cache fails the following
Open()
will succeed (i.e. database is surely closed)?For the test purposes I've added debug log in
evictcallback
, so I'm sure that expirable cache exec this callback. Also, according to code, all access to the cache was done under the internal mutex - soonEvict
will be executed before getting from cache.47209982e1
to032d89110a
032d89110a
tob92b00df4c