How to Detect and Fix Redis Performance Issues: A Complete Guide

Redis Performance Issues?

Redis is a critical component for caching, login sessions, leaderboards, etc. When request latency rises, the whole system can avalanche.

During a high‑traffic event the author experienced “Could not get a resource from the pool” errors, high connection counts, and MySQL overload caused by missing Redis cache.

Baseline Latency Measurement

Use redis-cli --intrinsic-latency (or --latency) to record maximum latency in milliseconds. Run the test for a sufficient period (e.g., 100 seconds) to capture peaks. The baseline is the highest observed latency; if current latency exceeds twice the baseline, the instance is considered slow.

redis-cli --latency -h host -p port

redis-cli --intrinsic-latency 100
Max latency so far: 4 microseconds.
...
Max latency so far: 3079 microseconds.
45026981 total runs (avg latency: 2.2209 microseconds)

Slow‑Command Monitoring

Identify O(N) commands (e.g., HGETALL, SMEMBERS, SORT) and replace them with O(1) or O(log N) alternatives. Enable the slowlog to record commands exceeding a configurable threshold (default 10 ms).

redis-cli CONFIG SET slowlog-log-slower-than 6000

View recent slow commands:

127.0.0.1:6381> SLOWLOG get 2
1) 1) (integer) 6
   2) (integer) 1458734263
   3) (integer) 74372
   4) 1) "hgetall"
      2) "max.dsp.blacklist"

Latency Monitoring (Redis 2.8.13+)

Set a latency threshold (e.g., 9 ms, three times the 3 ms baseline) with CONFIG SET latency-monitor-threshold 9. The command latency latest shows recent events.

127.0.0.1:6379> latency latest
1) "command"
   (integer) 1645330616
   (integer) 2003
   (integer) 2003

Network‑Induced Latency

Each command incurs a round‑trip time (RTT). Use pipelining to batch commands and reduce RTT overhead.

Fork‑Generated RDB Latency

Creating an RDB snapshot forks a background process, which blocks the main thread and uses copy‑on‑write (COW). Large instances can cause noticeable pauses.

Transparent Huge Pages (THP)

THP allocates 2 MB pages; during RDB generation Redis may copy an entire 2 MB page even for tiny writes, increasing latency. Disable THP with:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Swap‑Induced Latency

When Redis memory exceeds physical RAM or other processes consume memory, the kernel swaps pages to disk, dramatically slowing Redis. Check swap usage via /proc/<pid>/smaps and look for non‑zero “Swap” values.

$ redis-cli info | grep process_id
process_id:13160
$ cat /proc/13160/smaps | egrep '^(Swap|Size)'
Size: 720896 kB
Swap: 12 kB

If swap usage is significant, increase RAM, isolate Redis on its own machine, or add more cluster nodes.

AOF and Disk I/O Latency

Configure appendfsync to no or everysec for cache‑oriented workloads. Disable no-appendfsync-on-rewrite during AOF rewrite to avoid fsync contention.

Expires‑Based Eviction

Redis evicts expired keys lazily or every 100 ms. When many keys expire simultaneously, the active‑expire cycle can block the server. Randomize expiration timestamps (e.g., add a small random offset) to spread the load.

Big‑Key Problems

Keys with large values (5 MB strings, 10 k list items, etc.) cause OOM, uneven cluster memory distribution, and blocking deletions. Detect them with tools like redis‑rdb‑tools and mitigate by splitting, using UNLINK, or redesigning data structures.

Checklist for Redis Slow‑down Diagnosis

Measure current baseline latency.

Enable slow‑log and latency‑monitor.

Identify and rewrite slow commands (use SCAN instead of KEYS).

Keep instance size between 2‑4 GB to avoid long RDB loads.

Disable transparent huge pages.

Monitor and eliminate swap usage.

Adjust AOF settings (e.g., no-appendfsync-on-rewrite).

Detect and split big keys, delete them with UNLINK.