Why Is Redis Slowing Down? Common Causes and How to Diagnose Them

Redis as an in‑memory database offers very high performance, but latency spikes can occur if you are unfamiliar with its internal mechanisms.

Complex Commands

When latency suddenly increases, first check Redis' slow‑log. Set a threshold (in microseconds) so only commands exceeding it are recorded, e.g.:

# Record commands that take longer than 5 ms
CONFIG SET slowlog-log-slower-than 5000
# Keep only the latest 1000 entries
CONFIG SET slowlog-max-len 1000

After configuring, query recent entries with:

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer)32693 # slowlog ID
   2) (integer)1593763337 # timestamp
   3) (integer)5299 # execution time (µs)
   4) 1) "LRANGE" "user_list_2000" "0" "-1"
2) 1) (integer)32692 ...

If you see O(n) commands such as sort, sunion, zunionstore operating on large data sets, they can cause high latency. The solution is to avoid high‑complexity commands and limit the amount of data processed per request.

Large Keys

When slow‑log shows only simple SET or DELETE commands, suspect large keys. Writing or deleting a huge key consumes memory allocation or release time. Avoid storing overly large values in a single key.

Redis provides a built‑in scanner for large keys: redis-cli -h $host -p $port --bigkeys -i 0.01 The command reports key size distribution by type. When scanning a live instance, limit the scan frequency with the -i interval to reduce QPS impact.

Expiration Bursts

Massive key expirations at a fixed point can cause latency spikes because Redis’ active expiration runs in the main thread. Active expiration randomly samples expired keys every 100 ms; if many keys expire simultaneously, the thread may block for up to 25 ms, which is not recorded in the slow‑log.

Search your code for expireat or pexpireat and spread expirations over random times. Example pseudo‑code:

# Randomly expire within 5 minutes after the original time
redis.expireat(key, expire_time + random(300))

Monitoring the expired_keys metric via INFO helps detect sudden bursts.

Memory Limit Reached

When maxmemory is set, each new write may trigger eviction. The eviction strategy (e.g., allkeys‑lru, volatile‑lru, allkeys‑random, etc.) determines how much CPU time is spent selecting keys to evict. Evicting large keys further increases latency.

Choosing an appropriate policy and, if necessary, sharding data across multiple instances can mitigate the impact.

Fork Overhead

Background RDB/AOF rewriting forks a child process. Forking copies the page table; with large memory footprints this can take seconds and block the main thread. The latest_fork_usec metric (microseconds) shows the last fork duration.

Avoid enabling AOF or RDB rewriting on heavily loaded instances, schedule backups during off‑peak hours, and prefer physical machines over VMs to reduce fork cost.

CPU Binding

Binding Redis to specific CPUs is discouraged because the forked child inherits the CPU affinity, leading to contention between parent and child during persistence, which raises latency.

AOF Settings

AOF writes commands to a log file. Three fsync policies exist: appendfsync always – safest but highest I/O cost. appendfsync everysec – balances safety (max 1 s data loss) and performance. appendfsync no – relies on OS, lowest safety.

For most workloads, everysec is recommended; disable AOF if data loss is acceptable.

Swap Usage

If Redis starts responding in hundreds of milliseconds or seconds, check whether the OS is swapping. Swapped memory dramatically slows access, effectively nullifying Redis’ in‑memory advantage. Free memory, restart the instance, or migrate to a larger machine.

Network Saturation

Even with a healthy Redis process, a saturated NIC causes packet loss and transmission delays, degrading performance. Monitor network traffic, alert on high utilization, and scale or migrate instances as needed.

Summary

Redis latency can stem from command complexity, large keys, expiration bursts, memory limits, fork overhead, AOF configuration, swap usage, and network saturation. Understanding Redis internals, choosing appropriate commands and eviction policies, and implementing comprehensive monitoring are essential for maintaining high performance.