Databases 18 min read

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.

Java Backend Technology
Java Backend Technology
Java Backend Technology
Why Redis Gets Slow: Common Latency Causes and How to Diagnose Them

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 1000

Query recent slowlog entries with:

SLOWLOG get 5

If 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

SET

or

DELETE

taking 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.01

The command runs a

SCAN

over all keys and reports size statistics per type. Use the

-i

interval 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

expireat

or

pexpireat

and 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_keys

via

INFO

and alert on sudden increases.

Memory Limit Reached

When

maxmemory

is 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_usec

via

INFO

to 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.

monitoringperformanceredislatencyPersistencememoryslowlog
Java Backend Technology
Written by

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!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.