Why Redis Gets Slow: Common Latency Causes and How to Diagnose Them
This article explains the typical reasons Redis latency spikes—such as high‑complexity commands, large keys, concentrated expirations, memory limits, fork overhead, CPU binding, AOF settings, swap usage, and network saturation—and provides practical steps to monitor, identify, and mitigate each issue.
Introduction
Redis is an in‑memory database with very high performance, often handling around 100k QPS per instance. However, latency can increase dramatically if the internal mechanisms are not understood or if the deployment is misconfigured.
Using High‑Complexity Commands
When latency spikes, first check the Redis slowlog. Set the slowlog threshold (e.g., 5 ms) and keep the latest 1000 entries:
CONFIG SET slowlog-log-slower-than 5000
CONFIG SET slowlog-max-len 1000Query recent slowlog entries with:
SLOWLOG get 5If your workload frequently runs
O(n)commands such as
sort,
sunion, or
zunionstore, or processes large data sets with these commands, execution time will increase.
Large Keys
If slowlog shows simple commands like
SETor
DELETEtaking long, suspect large keys. Writing or deleting a huge key consumes memory allocation and release time.
Scan for big keys using the built‑in tool:
redis-cli -h $host -p $port --bigkeys -i 0.01The command runs a
SCANover all keys and reports size statistics per type. Use the
-iinterval to limit impact on QPS.
Concentrated Expiration
When many keys expire at the same moment, Redis must delete them, causing latency spikes that are not recorded in the slowlog because expiration runs before command execution.
Search the code for
expireator
pexpireatand add a random offset to spread expirations:
# Randomly expire within 5 minutes after the target time
redis.expireat(key, expire_time + random(300))Monitor
expired_keysvia
INFOand alert on sudden increases.
Memory Limit Reached
When
maxmemoryis reached, Redis evicts keys according to the configured policy (e.g.,
allkeys-lru,
volatile-lru,
allkeys-random, etc.). Eviction adds CPU overhead, especially for large keys, and can increase latency.
Fork Overhead
RDB snapshots and AOF rewrites fork a child process. Forking copies page tables; with large memory this can take seconds and block the main thread. Check
latest_fork_usecvia
INFOto see the last fork duration.
Avoid enabling AOF or RDB rewrites on heavily loaded instances, and schedule them during low‑traffic periods.
CPU Binding
Binding Redis to specific CPUs harms performance during persistence because the forked child inherits the CPU affinity and competes for CPU cycles, increasing latency.
AOF Configuration
Three fsync policies exist:
appendfsync always: safest but highest latency.
appendfsync everysec: balances safety (max 1 s data loss) and performance.
appendfsync no: relies on OS, lowest safety.
Recommended setting is
appendfsync everysec.
Swap Usage
If Redis starts swapping, latency can reach hundreds of milliseconds. Detect swap usage, free memory, and restart instances (preferably after a master‑slave switchover) to clear swap.
Network Saturation
High network load can cause packet loss and increased latency. Monitor NIC traffic, and if a Redis instance consumes excessive bandwidth, consider scaling out or moving the instance.
Conclusion
Redis latency can stem from both application‑level misuse (complex commands, large keys, concentrated expirations) and operational factors (memory limits, fork overhead, CPU binding, AOF settings, swap, and network saturation). Understanding these mechanisms and monitoring relevant metrics enables effective diagnosis and mitigation.
Java Backend Technology
Focus on Java-related technologies: SSM, Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading. Occasionally cover DevOps tools like Jenkins, Nexus, Docker, and ELK. Also share technical insights from time to time, committed to Java full-stack development!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.