Why Is My Redis Slowing Down? 10 Common Causes and How to Fix Them

1. Why Redis Gets Slow

1.1 Is Redis really slower?

Run a baseline latency test on the Redis server itself to know the normal latency for your hardware. Use

./redis-cli --intrinsic-latency 120

to measure the maximum response latency over 60 seconds, then compare it with the latency observed in production.

<code>./redis-cli --intrinsic-latency 120
Max latency so far: 119 microseconds.
36481658 total runs (avg latency: 3.2893 microseconds).
</code>

If the observed latency is more than twice the baseline, the instance is considered slow.

1.2 Network impact

Test the network limit with tools like

iperf

to ensure that network latency is not the bottleneck.

<code># Server side
iperf -s -p 12345 -i 1 -M
# Client side
iperf -c <server_ip> -p 12345 -i 1 -t 10 -w 20K
</code>

2. High‑complexity commands

Check the slowlog for commands with O(N) or higher complexity (e.g.,

SORT

,

SUNION

,

ZUNIONSTORE

) or O(N) commands with a very large

N

. Such commands consume excessive CPU or network resources.

3. Big keys (bigkey)

If simple commands like

SET

or

DEL

appear in the slowlog, investigate big keys with

redis-cli --bigkeys

. The command reports the largest keys per data type and their memory impact.

<code>redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 1
Sampled 829675 keys in the keyspace!
Biggest string found 'key:291880' has 10 bytes
Biggest list found 'mylist:004' has 40 items
...</code>

When scanning big keys, limit the scan frequency with the

-i

interval option to avoid a sudden OPS spike.

4. Concentrated expirations

Mass expirations at the same timestamp can cause a latency spike because the active expiration task runs in the main thread. Spread expirations by adding a random offset or enable

lazyfree-lazy-expire

(Redis 4.0+).

5. Memory reaching maxmemory

When the instance hits

maxmemory

, Redis evicts keys according to the configured policy (e.g.,

allkeys-lru

,

volatile-lru

,

allkeys-random

, etc.). Eviction itself consumes CPU and can increase latency, especially for big keys.

6. Fork overhead

Background RDB/AOF rewrite creates a child process via

fork

. Fork time grows with instance size and can block the main thread. Monitor

latest_fork_usec

via

INFO

to detect long forks.

<code># INFO output
latest_fork_usec:59477
</code>

7. Transparent huge pages

When huge pages are enabled, each write may trigger a 2 MB memory allocation, dramatically increasing latency for small writes. Disable it by setting

/sys/kernel/mm/transparent_hugepage/enabled

to

never

.

8. CPU binding

Binding Redis to a single logical CPU can cause contention between the main thread and background processes. Bind Redis to multiple cores of the same physical CPU, or use Redis 6.0+ CPU‑affinity settings (

server_cpulist

,

bio_cpulist

, etc.).

9. Swap usage

If the instance starts swapping, latency spikes to hundreds of milliseconds. Check swap with

cat /proc/<pid>/smaps | egrep '^(Swap|Size)'

and increase physical memory or add more Redis nodes.

10. Memory fragmentation

High

mem_fragmentation_ratio

(e.g., >1.5) indicates inefficient memory use. In Redis 4.0+ you can enable

activedefrag yes

, but be aware that defragmentation also consumes CPU.

<code># INFO memory
mem_fragmentation_ratio:1.45
</code>

2. Optimization Checklist

Avoid O(N) commands or keep

N

≤ 300.

Spread key expirations with a random offset.

Prevent big‑key eviction delays by using

lazyfree-lazy-eviction

or splitting data across instances.

Limit instance size (<10 GB) to reduce fork time.

Configure persistence wisely: disable AOF or use

appendfsync everysec

only if disk I/O is not a bottleneck.

Disable transparent huge pages.

Bind Redis to appropriate CPU cores (Redis 6.0+).

Monitor

INFO

metrics (latency, ops, memory, swap, fragmentation) and set alerts.