Eviction & Expiration

TTL returns the remaining seconds, -1 if the key exists with no expiry, and -2 if the key does not exist. PTTL is the same in milliseconds. PERSIST key removes the expiry and keeps the value, returning 1 if an expiry was removed, 0 otherwise.

Redis keeps no global LRU list. When memory exceeds maxmemory it picks maxmemory-samples random keys (default 5), reads the last-access timestamp stored in each key's object header, and evicts the idlest. More samples means better accuracy and more CPU.

Set notify-keyspace-events to a string of flags; empty means off. You must include K (keyspace channels) and/or E (keyevent channels) plus at least one event class such as g generic, $ string, l list, x expired, e evicted, or A for all classes. Example: Ex.

It repeatedly samples about 20 random keys from the table of keys with a TTL, deletes the expired ones, and loops again if more than 25% of the sample was expired. Time-boxed per run, so it bounds stale keys statistically, not exactly.

INFO memory for the totals, MEMORY STATS for the breakdown and bytes-per-key, MEMORY DOCTOR for hints, MEMORY USAGE <key> for one key's bytes, and redis-cli --bigkeys (largest by element count) or --memkeys (largest by bytes) to find offenders. Never KEYS *.

volatile-* policies only consider keys that have a TTL. If too few keys are volatile, Redis runs out of eviction candidates and behaves like noeviction — writes fail with OOM errors even though most of the keyspace is untouched. allkeys-* policies consider every key.

The default policy is noeviction: Redis deletes nothing. Reads still work, but any command that would use more memory is rejected with an error starting "OOM command not allowed when used memory > 'maxmemory'". Keys with TTLs still expire normally.

Commands that replace the whole value — notably SET — clear the TTL, making the key permanent. Commands that modify a value in place (APPEND, INCR, LPUSH, HSET, SADD, ZADD) keep it. SET key value KEEPTTL (Redis 6.0+) replaces the value while retaining the existing expiry.

Keyspace notifications are fire-and-forget Pub/Sub: no persistence, no acknowledgement, no redelivery. A disconnected, slow, restarting or newly deployed consumer loses events permanently, and every subscriber gets a copy, so jobs are silently dropped or run twice. Use a sorted set of due timestamps polled atomically instead.

Redis serves commands on one thread, so any whole-key operation on a giant key - reading it, deleting it, migrating it, replicating it - stalls every other client. It also unbalances shards and cannot be split. Fix by sharding the key and reading it in cursor-based chunks.

A keyspace channel is named after the key and its message is the event name; a keyevent channel is named after the event and its message is the key name. To catch every expiry in database 0 subscribe to keyevent@0:expired.

Under an LRU policy the 24-bit field holds a coarse clock value in seconds, taken from a cached server clock refreshed about once per second. Idle time is now minus that value. Twenty-four seconds-resolution bits wrap after roughly 194 days, and the idle-time calculation compensates for the wrap.

NX sets the expiry only if the key has none; XX only if it already has one; GT only if the new deadline is later than the current one; LT only if it is earlier. A key with no expiry counts as infinite, so GT never applies to it and LT always does.

Redis keeps a small array of the best eviction candidates seen so far, sorted by idle time. Each round's random sample is merged into that pool, and the pool's best entry is evicted. The pool remembers good candidates across rounds, so quality no longer depends on one lucky sample.

The 8 bits hold a probabilistic logarithmic counter, not a hit count. Each access increments it only with probability decreasing as the counter grows, controlled by lfu-log-factor, so the counter saturates at 255 after millions of hits. OBJECT FREQ reads it.

The event is published when the key is actually deleted, not when its TTL logically elapses. Deletion happens either when something touches the key or when the background expiry cycle happens to sample it, so an untouched key in a large keyspace can wait far beyond its TTL.

Replicas never expire keys on their own. They wait for the primary to send an explicit DEL/UNLINK when it reclaims the key. Meanwhile a replica read masks the key as missing, so its key count and memory can exceed the primary's.

The ratio is resident memory divided by allocated memory. 1.9 means the process holds nearly twice what Redis uses - real fragmentation or transient overhead; consider activedefrag or a restart. Below 1, like 0.7, means part of the process is swapped to disk, which is a latency emergency.

LRU suits recency-driven traffic but a batch scan can flush the hot set. LFU keeps stable popular keys and resists one-off scans, at the cost of adapting slower to shifting popularity. Random is cheapest and fine when access is near-uniform or keys are equally valuable.

EXPIREAT takes an absolute Unix timestamp rather than a relative duration. Redis stores every expiry as an absolute millisecond timestamp anyway — EXPIRE is converted internally — and replicates and persists it as PEXPIREAT, so deadlines survive restarts and never drift on replicas.

No single policy is safe for both: allkeys-* can delete sessions and queued jobs, noeviction turns cache growth into write outages. Split into separate instances. If you cannot, use volatile-* with enforced TTLs on cache keys only, and keep 25–30% RAM headroom.

No. By default a replica ignores its own maxmemory for replicated data (replica-ignore-maxmemory yes). The primary evicts and propagates an explicit DEL/UNLINK down the replication stream; the replica just applies it, keeping datasets identical.

Each database holds a second dictionary, expires, mapping keys that have a TTL to an absolute millisecond deadline — so a volatile key costs an extra hash-table entry. Expiry is per top-level key; Redis 7.4 added HEXPIRE for per-field hash TTLs, and before that you emulated it.

lfu-decay-time (minutes) is how fast an untouched counter decays so once-hot keys can fall out; lfu-log-factor sets how many accesses fit on the 0-255 scale; maxmemory-samples sets how many candidates each eviction round inspects. Tune by sampling OBJECT FREQ on known hot and cold keys.