Redis’s INFO command is a goldmine for understanding what’s happening under the hood, but most people only ever look at a handful of metrics. The real magic happens when you dig into the less obvious ones, which can tell you about impending issues long before they manifest as outright errors.
Let’s see INFO in action. Imagine you’ve got a Redis instance running, and you want to get a snapshot of its state.
redis-cli INFO memory
This gives you a snippet like:
# Memory
used_memory:14567890
used_memory_human:13.89M
used_memory_rss:23456789
used_memory_rss_human:22.37M
maxmemory:0
maxmemory_policy:noeviction
total_system_memory:1677721600
total_system_memory_human:1.59G
used_memory_peak:15000000
used_memory_peak_human:14.30M
mem_fragmentation_ratio:1.61
mem_fragmentation_bytes:-8888899
allocator_resident:21000000
allocator_active:17000000
allocator_allocated:14567890
This output isn’t just raw numbers; it’s a story about how your Redis instance is using memory, how much it can use, and how efficiently it’s doing it.
The core problem Redis solves is providing extremely fast, in-memory data storage with rich data structures. To do this efficiently, it needs to manage its memory meticulously. The INFO command’s memory section is your window into that management. You’re looking at how much data you’re storing (used_memory), how much physical RAM Redis is actually consuming (used_memory_rss), and how Redis is allocating and deallocating that memory (allocator_* fields, mem_fragmentation_bytes, mem_fragmentation_ratio). You also see your configured limits (maxmemory) and the overall system’s available memory (total_system_memory).
The used_memory metric is the amount of memory Redis claims it’s using for its data structures and internal overhead. It’s the most direct measure of your data footprint. used_memory_rss is what the operating system reports Redis is using, including any shared libraries or memory that might be swapped out. The difference between used_memory_rss and used_memory is often due to memory fragmentation and the allocator’s overhead. A mem_fragmentation_ratio significantly greater than 1 indicates fragmentation, where Redis might be holding onto more memory than it actively uses due to how the memory allocator works. Conversely, a ratio less than 1 (though less common) can suggest that other processes are sharing memory with Redis, which isn’t ideal. mem_fragmentation_bytes gives you the raw difference in bytes between RSS and claimed memory.
The allocator_resident metric is the total memory that the memory allocator has reserved from the OS. allocator_active is the portion of that reserved memory that is currently in use by Redis. allocator_allocated is the memory that the allocator has actually handed out to Redis for its data structures. The gap between allocator_resident and allocator_active is also fragmentation, but at the allocator level.
You control Redis’s memory usage primarily through two levers: the data you store and the maxmemory configuration. maxmemory sets an absolute limit on how much memory Redis will use for its dataset. When this limit is reached, Redis’s behavior is dictated by maxmemory_policy. Policies like volatile-lru, allkeys-lru, volatile-ttl, volatile-random, allkeys-random, or noeviction determine what Redis does next – typically evicting keys to make space or returning errors.
When you see used_memory_peak, it’s not just the highest used_memory value ever recorded; it’s the actual peak memory usage of the Redis process. This can be higher than your current used_memory due to fragmentation that hasn’t been reclaimed or data that was previously stored and then deleted.
The real trick to mastering INFO is understanding the interplay between used_memory_rss and total_system_memory. Most people watch used_memory, but if your used_memory_rss starts creeping up towards total_system_memory, you’re in for trouble, even if used_memory is still well below maxmemory. This is because Redis itself might not be the direct culprit for exceeding system limits; the OS’s memory allocator can behave in ways that lead to high RSS even for moderate used_memory. The mem_fragmentation_ratio is your early warning system here. If it’s consistently above 1.5 or 2, you should investigate.
This deep dive into memory metrics is crucial for understanding how Redis behaves under load and preventing OOM (Out Of Memory) errors, which can lead to Redis crashing or returning errors to your application.
Next, you’ll want to understand how to monitor Redis’s network performance using INFO networking.