Redis memory and latency field guide

Symptom. Writes start failing with out-of-memory errors, or hit rates fall as keys are evicted, usually at the busiest hour. Memory looks stable on a daily graph and then steps up to the limit. A pattern we see in support work is a maxmemory chosen at go-live that no one revisited as the dataset and replication buffers grew.

Check. redis-cli INFO memory gives used_memory, used_memory_peak, maxmemory and mem_clients_normal; CONFIG GET maxmemory-policy gives the policy; INFO stats gives evicted_keys. MEMORY STATS breaks usage into dataset and overhead, and MEMORY DOCTOR reports known problems. With the default noeviction policy, Redis returns an error on commands that would cache new data once the limit is reached.

Fix. Set an explicit maxmemory. Redis's administration guide says to calculate the overhead for Redis other than data, and the fragmentation overhead: if you think you have 10 GB of free memory, set it to 8 or 9. Pick an eviction policy on purpose, then alert before the ceiling rather than at it.

Symptom. Latency jumps, or memory leaps toward the limit, at the time of an RDB snapshot, an AOF rewrite or a replica full sync. On a write-heavy instance the same moment can end in an out-of-memory kill of the Redis process. Redis forks to save, and the fork itself and the copy-on-write that follows are both visible in the statistics.

Check. INFO stats reports latest_fork_usec, the duration of the latest fork. INFO persistence reports rdb_last_cow_size, the copy-on-write memory during the last RDB save, and current_cow_size while a child is running. LATENCY DOCTOR lists fork events once the latency monitor is on. Check that transparent huge pages are disabled: cat /sys/kernel/mm/transparent_hugepage/enabled.

Fix. Redis's guide warns that a write-heavy instance can use up to 2 times its normal memory while saving or rewriting, so size headroom for that peak. Disable transparent huge pages, which the latency guide says cause big latency and memory use after a fork. Set vm.overcommit_memory = 1. Run saves on a replica where the design allows, and on EC2 use modern HVM instances, because the docs measured fork time at roughly 9 to 13 milliseconds per GB on physical machines and VMware, and 239 milliseconds per GB on an old Xen instance type.

Symptom. Latency is fine for hours, then climbs during a sustained write or read load and stays high until traffic eases. CPU on the node looks busy rather than saturated, memory is fine, and the slow log shows nothing unusual. This is a pattern we see on small cloud cache nodes sized for a test and left in production.

Check. On Amazon ElastiCache T4g and T3 nodes, look at the CPUCreditBalance and CPUCreditUsage CloudWatch metrics. AWS documents that these nodes burst until the accrued credits are exhausted, and that as credits run low performance is gradually lowered to baseline. The baseline is 10 percent of a vCPU on a micro node and 20 percent on small and medium nodes. On a VM you manage, run redis-cli --intrinsic-latency 100 on the server itself to see the latency the host imposes before Redis does anything.

Fix. Move to a node family without CPU credits for any instance with sustained load, or reduce the load. AWS describes these nodes as suited to workloads whose average CPU utilization stays below baseline, which is rarely true of a busy cache.

Symptom. Memory rises well beyond what the key count suggests, often after an index is created or rebuilt, and an index rebuild takes long enough to affect traffic. Teams call it a leak. Often it is index memory that was never part of the sizing.

Check. FT.INFO <index> reports num_docs, inverted_sz_mb, total_index_memory_sz_mb, the memory consumed by all indexes, and an indexing flag that shows whether the index is current. Compare that with INFO memory and with MEMORY USAGE on sampled keys to see what is dataset and what is index.

Fix. Index only the fields you query. Add the index memory to the sizing model next to the dataset, replication buffers and fork headroom. Rebuild indexes off-peak after rehearsing the rebuild time on a copy, and read the release notes of the module or Redis version you run for fixes before concluding anything about a leak.

Symptom. Client timeouts at peak while the server reports healthy, main-thread CPU high on flat traffic, and p99 latency far above the median. Redis serves requests one at a time, so one slow command delays everything behind it. KEYS in production is the classic cause, and Redis's latency guide calls it a very common source of latency.

Check. SLOWLOG GET 10 lists the slowest recent commands. redis-cli --latency measures round-trip latency from the client side, and --latency-history samples it over time. redis-cli --bigkeys and --memkeys scan for the largest keys. Latency monitoring is off by default; enable it with CONFIG SET latency-monitor-threshold 100, the example in Redis's documentation, and read LATENCY LATEST and LATENCY DOCTOR.

Fix. Replace KEYS with SCAN and its variants, split very large collections, move slow queries to a replica, pipeline round trips, and size client pools above peak concurrency. Avoid many keys expiring in the same second, which the latency guide says can block Redis while it clears expired keys.

Four rules cover most sizing mistakes. Each is from redis.io, so you can check it.

Alert on trends toward a limit, not on the limit. These are the signals the five patterns above produce.

Call before the fix touches replication, persistence or cluster topology, where a wrong step can lose data, and when a pattern above recurs after you have fixed it. A Redis health check reads all of the signals in this guide on your deployment, ranks the findings by what will fail first, and ends in a written fix list. It takes one to four weeks, and a quote request is answered within 1 hour. If the instance is down now, 24/7 support carries a 15-minute emergency response.