How to Monitor and Optimize Redis Performance

The Redis INFO command returns data in ten sections (server, clients, memory, persistence, stats, replication, cpu, commandstats, cluster, keyspace); focusing on five key metrics—memory, command processing, latency, key eviction, and fragmentation—helps quickly locate performance bottlenecks.

Memory : The info memory output shows fields like used_memory, used_memory_rss, mem_fragmentation_ratio, and the allocator. High used_memory relative to available memory can trigger swapping, causing severe latency. Reducing memory usage can be done by using 32‑bit instances for small datasets, preferring hash structures, setting key expirations, and configuring maxmemory and maxmemory-policy (e.g., volatile-ttl or allkeys-lru).

Command Processing : total_commands_processed from info stats indicates overall command volume. A drop in instantaneous_ops_per_sec or rising latency often means command queues are backing up or slow commands are blocking the single‑threaded Redis server. Mitigate this by using multi‑argument commands (e.g., mset, mget, lpush), pipelines, or avoiding high‑complexity operations on large collections.

Latency : Redis latency isn’t in INFO; use redis-cli --latency to measure round‑trip times. Slowlog (default >10 ms) records commands that exceed a threshold, showing command ID, timestamp, execution time (µs), and the command itself. Adjust the threshold with config set slowlog-log-slower-than 5000 if needed.

Client Connections : info clients reveals the number of connected clients. Excessive connections (e.g., >5000) can degrade performance; adjust maxclients in redis.conf or via config set maxclients to a safe ceiling (typically 110‑150 % of expected peak).

Fragmentation : mem_fragmentation_ratio = used_memory_rss / used_memory. Values slightly above 1 are normal; >1.5 indicates significant fragmentation, which may lead to swapping. Remedies include restarting Redis, limiting memory usage, or changing the memory allocator (jemalloc, libc, tcmalloc).

Key Eviction : The evicted_keys metric shows keys removed due to maxmemory limits. Monitoring this helps ensure the eviction policy aligns with workload (e.g., volatile-ttl for expiring keys, allkeys-lru for LRU eviction). Increasing maxmemory or sharding data across multiple instances can also reduce evictions.

By regularly collecting INFO output, tracking these metrics, and applying the suggested configuration tweaks, you can maintain low latency and high throughput for Redis deployments.