Redis Performance Degradation: Root Causes and Optimization Techniques

Redis can appear to slow down when its response latency exceeds the baseline measured on the production server. Start by measuring the intrinsic latency with ./redis-cli --intrinsic-latency 120 , which reports the maximum latency observed in a 60‑second window.

Enable and inspect the slowlog to see commands that exceed a configurable threshold: CONFIG SET slowlog-log-slower-than 5000 and CONFIG SET slowlog-max-len 500 . A latency that is twice the baseline usually indicates a problem.

Typical causes include:

Running O(N) or higher‑complexity commands (e.g., SORT , SUNION , ZUNIONSTORE ) or the same commands on very large N.

Presence of big keys; detect them with redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 1 and avoid full scans or use lazy deletion.

Mass expirations at the same moment, which trigger passive and active expiration mechanisms.

Memory reaching maxmemory and eviction policies (allkeys‑lru, volatile‑lru, etc.) causing extra CPU work.

Fork overhead during RDB/AOF rewrite or replication, where the parent process must copy its page tables; large instances increase latest_fork_usec time.

Enabled transparent hugepages (large pages) that increase copy‑on‑write cost.

Swap usage, which forces Redis to read/write data from disk and dramatically raises latency.

CPU binding to a single logical core, causing contention between the main thread, background threads, and forked processes.

Optimization steps:

Avoid high‑complexity commands or break them into smaller batches (N ≤ 300).

Use SCAN to iterate over big keys and delete them lazily with UNLINK or enable lazyfree-lazy-eviction yes .

Randomize expiration times to spread the load.

Choose a lighter eviction policy (e.g., allkeys‑random ) or increase maxmemory limits.

Keep instance size below ~10 GB to reduce fork time, and schedule RDB/AOF rewrites during low‑traffic windows.

Disable transparent hugepages: echo never > /sys/kernel/mm/transparent_hugepage/enabled .

Monitor swap and memory fragmentation via INFO MEMORY (e.g., mem_fragmentation_ratio ) and restart or reshard if needed.

Bind CPUs separately in Redis 6.0+: server_cpulist 0-7:2 , bio_cpulist 1,3 , aof_rewrite_cpulist 8-11 , bgsave_cpulist 1,10-11 .

Tune AOF: set no-appendfsync-on-rewrite yes or use appendfsync everysec while accepting up‑to‑1‑second data loss.

Continuously monitor key metrics with INFO (e.g., expired_keys , latest_fork_usec , lazyfree_pending_objects ) and set alerts for sudden spikes. By combining proper benchmarking, configuration tuning, and operational best practices, Redis latency can be kept within acceptable bounds.