Redis is known for being fast and efficient, which is why it’s great for caching, processing real-time data, and managing user sessions. Most people watch basic things like the memory, the CPU, and how often keys are removed. But there are other important numbers that can give you a much better idea of how well Redis is really working.
In this blog, we’ll look at eight Redis metrics you might not be tracking. We’ll explain why they matter and how watching them can help you avoid performance problems and unexpected crashes.
1. Memory use efficiency (the fragmentation ratio)
Redis uses ways to store data in memory that can sometimes lead to wasted space, even if it looks like you have enough memory. The mem_fragmentation_ratio field shows how well Redis is using the memory it has.
Why it matters
-
A high ratio (over 1.5) means that memory is being wasted because it’s not organized well.
-
This can cause Redis to use more memory and cost you more in the cloud.
How to fix it
-
Change the maxmemory-policy setting to help Redis manage memory better.
-
Adjust the settings for jemalloc, the tool Redis uses to handle memory.
2. The cache hit rate (keyspace hits vs. keyspace misses)
The Redis hit rate is how often Redis finds the data it’s asked for. This rate calculated by dividing the number of times Redis found the data (keyspace_hits) by the total number of times it was asked (keyspace_hits + keyspace_misses). A low rate means Redis isn’t doing a good job of caching.
Why it matters
-
A low hit rate (under 80%) means Redis often can’t find the data, so it has to go to the main database more, which slows things down.
How to fix it
-
Change how long data stays in the cache (time to live (TTL) values).
-
Make the cache bigger or use a system (like the least recently used policy) that keeps the most used data.
3. Removed and expired keys
Redis removes keys when it runs out of memory, and keys also disappear when their time limit (TTL) is up. Watching evicted_keys (removed due to memory) and expired_keys (removed due to time) helps you know if Redis is working as expected.
Why it matters
-
If there are lots of evicted keys, it might mean your Redis system doesn’t have enough memory.
-
A sudden jump in expired keys could mean you’re losing data you didn’t expect to.
How to fix it
-
Change Redis’ memory rules and how it decides what to remove.
-
Make sure the time limits you set for keys match what your application needs.
4. Client buffer and waiting commands
Redis keeps a buffer for each client to handle network traffic. The client_output_buffer_limit metric shows how much data is waiting to be sent to clients.
Why it matters
-
A large client buffer can mean there’s a problem with the network or that clients are slow at processing data.
-
Commands waiting in line can delay important requests.
How to fix it
-
Check your network setup and increase the bandwidth if needed.
-
Add more Redis systems to spread the work.
5. Replication lag
If you have Redis set up with a main system (primary) and copies (replicas), replication lag is the delay between them.
Why it matters
-
A big lag (over one second) means the copies might have old data.
-
This can cause problems with data consistency if your main system fails.
How to fix it
-
Check the network connection between the main and copy systems.
-
Watch and adjust how often the copies sync with the main system.
6. Slow log entries
Redis has a feature that logs commands that take longer than a certain amount of time. Watching these slow log entries helps you find commands that are slowing things down.
Why it matters
-
If there are lots of slow commands, it means Redis isn’t running efficiently.
How to fix it
-
Find and improve the slow commands (for example, don’t use KEYS on large amounts of data).
-
Use SCAN instead of KEYS for large datasets.
7. Rejected connections
Redis will refuse new connections when it reaches its limit (maxclients). Watching rejected_connections helps you see if you’re hitting this limit before it causes problems.
Why it matters
-
Rejected connections mean new parts of your application can’t talk to Redis.
How to fix it
-
Increase the maxclients setting or spread connections across multiple Redis systems.
-
Use connection pooling in your application to reuse connections.
8. AOF rewrite activity
If Redis uses a system, like the append-only file (AOF), to save data to the disk, it sometimes rewrites this file. Watching aof_rewrite_in_progress and can help you avoid disk issues.
Why it matters
-
Frequent rewrites can put a lot of stress on your disk, slowing down Redis.
How to fix it
-
Change the AOF rewrite rules to avoid writing to the disk too often.
-
Adjust Redis’ save settings based on how important your data is.
Monitor Redis the right way
To really know how well Redis is performing, you need to look beyond the basic numbers. By tracking these metrics, you can catch problems early, use your resources better, and make sure your Redis system is stable and fast.
Using a good monitoring tool like ManageEngine Applications Manager can give you the deep insights you need to understand your Redis system’s health, find issues quickly, and keep your applications running smoothly for your users.
Curious to explore Redis monitoring capabilities in more depth? Check out these helpful resources:
Want to see how Applications Manager can help you monitor Redis effectively? Download a free, 30-day trial now!
