DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Data Engineering
  3. Databases
  4. Crucial Redis Monitoring Metrics You Need to Watch

Crucial Redis Monitoring Metrics You Need to Watch

If you're running Redis, then you should be monitoring these six key metrics (especially from a database performance perspective).

Vishal Kumawat user avatar by
Vishal Kumawat
·
Apr. 03, 17 · Opinion
Like (3)
Save
Tweet
Share
8.25K Views

Join the DZone community and get the full member experience.

Join For Free

Redis is an in-memory database that provides blazingly fast performance. This makes it a compelling alternative to disk-based databases when performance is a concern. You might already be using Redis to power your performance-sensitive applications. How do you ensure that your Redis deployment is healthy and meeting your requirements?

You will need to know which Redis monitoring metrics to watch and a  tool to monitor these critical server metrics to ensure its health. Redis returns a big list of database metrics when you run the info command on Redis shell. You can pick a smart selection of relevant metrics from these. And these can help you ensure your system’s health and to quickly perform root cause analysis of any performance-related issue you might be encountering.

This blog post lists the important database metrics to monitor. We will look at each metric from a database performance perspective and discuss the common issues and solutions associated with them.

1. Performance Metric: Throughput

Throughput tells you how many database operations your server is performing in a particular time duration. It is dependent upon your application workload and its business logic. By looking at the history of throughput, you can infer the pattern of load on a server e.g. peak load, the frequency of peak load, the time frames of peak load, average load etc.

You can collect throughput metric values for all the commands run on the Redis server by executing info commandstats.

127.0 .0 .1: 6379 > info commandstats# Commandstats
cmdstat_get: calls = 797, usec = 4041, usec_per_call = 5.07
cmdstat_append: calls = 797, usec = 4480, usec_per_call = 5.62
cmdstat_expire: calls = 797, usec = 5471, usec_per_call = 6.86
cmdstat_auth: calls = 147, usec = 288, usec_per_call = 1.96
cmdstat_info: calls = 46, usec = 902, usec_per_call = 19.61
cmdstat_config: calls = 2, usec = 130, usec_per_call = 65.00
cmdstat_eval: calls = 796, usec = 36950, usec_per_call = 46.42
cmdstat_command: calls = 796, usec = 8578, usec_per_call = 10.78

Throughput

Redis groups its various commands into connection, server, cluster, generic, etc. ScaleGrid Redis monitoring aggregates the throughput of various commands into one of the above-mentioned groups. The throughput is represented as a stacked area graph, where the height of each colored area provides the throughput of a group of commands.

A reduced throughput could generally indicate that the server gets fewer queries. It could also indicate a potential issue, say, an expensive query. Similarly, an increased throughput signifies intensive workload on a server and a larger latency.

2. Memory Utilization

Memory is a critical resource for Redis performance. Used memory defines the total number of bytes allocated by Redis using its allocator (either standard libc, jemalloc, or an alternative allocator such as tcmalloc).

You can collect all memory utilization metrics data for a Redis instance by running info memory.

127.0 .0 .1: 6379 > info memory# Memory
used_memory: 1007280
used_memory_human: 983.67 K
used_memory_rss: 2002944
used_memory_rss_human: 1.91 M
used_memory_peak: 1008128
used_memory_peak_human: 984.50 K

Screen Shot 2017-03-05 at 11.46.02 PM

Sometimes, when Redis is configured with no max memory limit, memory usage will eventually reach system memory, and the server will start throwing “Out of Memory” errors. At other times, Redis is configured with a max memory limit but noeviction policy. This would cause the server not to evict any keys, thus preventing any writes until memory is freed. The solution to such problems would be configuring Redis with max memory and some eviction policy. In this case, the server starts evicting keys using eviction policy as memory usage reaches the max.

Memory RSS (Resident Set Size) is the number of bytes that the operating system has allocated to Redis. If the ratio of memory_rss to memory_used’ is greater than ~1.5, then it signifies memory fragmentation. The fragmented memory can be recovered by restarting the server.

3. Cache Hit Ratio

The cache hit ratio represents the efficiency of cache usage. Mathematically, it is defined as (Total key hits)/ (Total keys hits + Total key misses).

info stats command provides keyspace_hits and keyspace_misses metric data to further calculate cache hit ratio for a running Redis instance.

127.0.0.1:6379> info stats
# Stats
.............
sync_partial_err:0
expired_keys:10
evicted_keys:12
keyspace_hits:4
keyspace_misses:15
pubsub_channels:0
pubsub_patterns:0
.............

If the cache hit ratio is lower than ~0.8 then a significant amount of the requested keys are evicted, expired, or do not exist at all. It is crucial to watch this metric while using Redis as a cache. Lower cache hit ratio results in larger latency as most of the requests are fetching data from the disk. It indicates that you need to increase the size of Redis cache to improve your application’s performance.

4. Active Connections

The number of connections is a limited resource which is either enforced by the operating system or by the Redis configuration. Monitoring the active connections helps you to ensure that you have sufficient connections to serve all your requests at peak time.

5. Evicted and Expired Keys

Redis supports various eviction policies that are used by the server when memory usage hits the max limit. A persistent positive value of this metric is an indication that you need to scale the memory up.

127.0 .0 .1: 6379 > info stats# Stats
 ..............
sync_partial_err: 0
expired_keys: 0
evicted_keys: 0
keyspace_hits: 0
keyspace_misses: 0
pubsub_channels: 0
pubsub_patterns: 0
 ..............

Redis supports TTL (time to live) property for each key. The server deletes the key if the associated TTL has elapsed. If the application does not define this property, it causes expired data to pile up in memory. A positive metric value shows that your expired data is being cleaned up properly.

6. Replication Metrics

connected_slaves metric informs the reachability of the slave server to a master. Slave unreachability could lead to higher read latency depending on the read load on a server.

127.0.0.1:6379> info replication# Replication
role:master/slave
connected_slaves:0/master_slave_io_seconds_ago:0
master_repl_offset:0
..............

master_slave_io_seconds_ago metric tells how much time elapses during the communication between a slave and the master. A higher value for this metric can be indicative of issues on the master/slave or some network problems. It further causes the slave to serve stale data.

Conclusion

We have mentioned some of the important metrics that will provide good visibility into the health and performance of your database server. There could be others that are relevant to your particular database servers and use cases. We would recommend going through and understanding all the metrics reported by “info” command.

Redis (company) Metric (unit) Database

Published at DZone with permission of Vishal Kumawat, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Is DevOps Dead?
  • Comparing Map.of() and New HashMap() in Java
  • 10 Best Ways to Level Up as a Developer
  • DevOps for Developers: Continuous Integration, GitHub Actions, and Sonar Cloud

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: