My redis cluster is configured with maxmem. The eviction policy is allkeys-lru. I want to know how long the keys are lasting on average before they are evicted. Every time a key is evicted, doesn't redis capture how long it lived for?
I was looking at INFO in redis-cli and I see these keyspace metrics:
# Keyspace
db5:keys=13502644,expires=0,avg_ttl=0
However, it seems that "avg_ttl" only corresponds to keys that expire; not keys that are evicted.
The only other relevant thing I can find are total counts:
expired_keys:0
evicted_keys:17026842
Neither of these help me answer the question: How long do keys normally last before they are evicted?
Comment From: madolson
@luxe We don't have any information about this in Redis, AFAIK. What is your use case for trying to understand that information?
Comment From: luxe
We use redis as a cache. It's difficult to know if our cache is undersized since we don't know the average lifetime of evicted keys. We often try to keep our cache warm by re-populating certain portions of it. However since we don't know the eviction rate, we don't know the rate at which we should re-run these population actions.
More generally, we are trying to answer the question: "How long do things stay in our cache?".
Redis has an avg_ttl, but it doesn't work for evictions.
I was considering adding super long TTLs to our keys, and switching our eviction policy to volatile-lru to see if that would cause the avg_ttl to be non-zero? If that doesn't work, maybe there is a redis query that lets me find the oldest key?
We could occasionally grab the oldest key and report it's age. That would be an equivalent metric to what I'm looking for.
Comment From: ptjm
Wouldn't it make more sense to shorten the TTL until you find a threshold where substantial numbers of keys start expiring rather than being evicted?
Another option would be to run randomkey many times and take the TTL of those keys.
A really expensive but arguably more accurate method would be to use keyspace notifications to track set/evicted/expired events. The notifications themselves only show the key and the event, so you'd have to keep track of everything to do with time yourself.
Comment From: Jeremy-Run
Can be combined with the hit ratio to estimate whether the memory is too small.
Comment From: madolson
Unfortunately we don't really have a way to compute the length of time the key has been alive, all we have a reference to is the "LRU" bits, which is the last access time. We don't want to pay the fixed "extra" cost to also include the creation time of the key.
Also worth mentioning that avg_ttl doesn't compute the same piece of information, it's just computing the "average" ttl of the items remaining in the database, which should be underestimating the average time the key exists until it's expired.
A known discussion we've talked about is we use "ref counts" on the Robject, which is a 32 bits (64 bits on 64 bit system) which is a lot of bits we could be using. Enough to store the creation date.
Comment From: luxe
Sounds like the easiest strategy for us will be to read through existing keys and get their last access time. The oldest timestamps we find will tell us how long unused keys stick around.