Redis Latency, Evictions and Persistence: Reading INFO Like an Incident Report

redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|evicted_keys|mem_fragmentation_ratio'
redis-cli INFO stats  | egrep 'keyspace_hits|keyspace_misses|rejected_connections|total_commands_processed'
redis-cli INFO persistence | egrep 'rdb_last_bgsave_status|aof_last_write_status|loading'
redis-cli INFO replication | egrep 'role|connected_slaves|master_link_status|master_repl_offset'
redis-cli --latency -h <host>            # live latency probe from the client side

These four blocks answer: is memory the problem, is traffic the problem, did persistence fail, and is replication healthy.

evicted_keys increasing and hit rate dropping (keyspace_hits/(hits+misses)) means the dataset outgrew maxmemory and the policy is throwing keys away. With noeviction (the dangerous default for caches) writes instead fail with OOM command not allowed when used memory > 'maxmemory'.

redis-cli CONFIG GET maxmemory maxmemory-policy
redis-cli INFO memory | grep evicted_keys

• For a cache: allkeys-lru (or allkeys-lfu for skewed popularity) is usually right — evictions are the cache working, not failing; the question is whether the hit rate stays acceptable.
• For a data store: never rely on eviction; size memory with headroom and alert at 80% of maxmemory.

redis-cli --bigkeys                 # samples the largest keys per type
redis-cli OBJECT ENCODING mykey     # ziplist vs hashtable matters a lot
redis-cli MEMORY USAGE mykey        # exact bytes for one key

Typical culprits: unbounded lists/streams (no MAXLEN), hashes that crossed the ziplist threshold into hashtable encoding, and keys with no TTL accumulating forever. A cache where "someone forgot expiry" is the most common eviction incident of all — audit with --bigkeys and redis-cli --scan | head plus TTL sampling.

Because one thread runs commands, any O(N) operation or background stall becomes everyone's latency. The built-in monitor for this:

redis-cli CONFIG SET latency-monitor-threshold 50   # log events over 50ms
redis-cli LATENCY LATEST
redis-cli LATENCY REPORT
redis-cli --latency-history -i 1                    # per-second view during the incident

The usual suspects, in order of frequency:

• Big keys: KEYS *, SMEMBERS on million-member sets, HGETALL on huge hashes. Replace with SCAN/SSCAN and paginated reads.
• Fork for RDB/AOF-rewrite: on hosts with many GBs and slow memory (or oversold VMs), the fork itself stalls the event loop. Watch latest_fork_usec; if it is in the hundreds of ms, schedule snapshots off-peak, reduce dataset size, or move to hosts with better memory bandwidth. Transparent Huge Pages amplifies this — Redis docs still recommend THP disabled.
• Swap: if mem_fragmentation_ratio is far above 1 and the host swaps, every touched page costs a disk fault. Redis should never swap; alert on host swap usage for the Redis box.

Disk-full is the parent of most persistence incidents: an RDB snapshot needs free space comparable to the dataset while writing.

redis-cli -h replica INFO replication
# master_link_status:down  → the replica cannot keep a link: network, auth, or timeout
# master_sync_in_progress:1 with a big offset → full resync in flight; expect latency on the master (fork)

• Frequent full resyncs (repl_transfer loops) mean the replication buffer (client-output-buffer-limit replica) is too small for the write rate during sync — increase it or improve the link.
• connected_slaves lower than expected: replicas failing auth (masterauth) show in the replica log, not the master's INFO.
• Use WAIT or replica offset comparison to verify your durability assumptions after a failover drill.

• Set maxmemory and an explicit policy on day one; alert on evicted_keys rate and on used_memory at 80%.
• Enable the latency monitor with a 25–50ms threshold and keep LATENCY REPORT output in your runbook.
• Keep THP disabled on Redis hosts and watch latest_fork_usec after every dataset growth.
• Alert on master_link_status and on disk free space of the persistence directory.
• Ban KEYS * in production (rename-command or ACL) and use SCAN-based tooling.