Redis

洞悉Redis技术内幕:缓存,数据结构,并发,集群与算法
帅旋
关注
充电
IT宅站长,技术博主,共享单车手,全网id:arthinking。

Redis性能监控常用指标

发布于 2021-06-16 | 更新于 2024-03-03

1、used_memory

used_memory:给Redis分配的内存总字节数

used_memory_human:以更易读懂的格式给出相同的值

用于判断是否由于内存交换引起的性能问题

如果used_memory超过了操作系统总可用内存,操作系统将开始进行内存交换,旧的内存部分将被写入磁盘,从磁盘写读写数据的速度比从内存中读写数据的速度慢了5个数量级,如果内存交换发生在Redis进程上,Redis的性能以及依赖Redis的任何应用程序性能将受到严重的影响。

跟踪内存使用情况,以解决性能问题

如果没有开启RDB,那么Redis可以使用的内存总量超过可用内存的95%。

如果开启了RDB,那么如果Redis使用超过45%的可用内存,就会变得有风险了。当然,这个比例也不是绝对的,如果Redis实例写比读的执行频率高很多,则需要尽可能保证这个比例。如果读比写频率高很多,那可以适当调高这个比例。

如何减少Redis内存占用?

  • 如果规划要存储的数据小于4GB,请使用32位的Redis实例,因为32位的指针大小是64位的一半,其内存占用小多了;
  • 为键设置过期时间;
  • 通过将maxmemory设置为可用内存的45%(未开启RDB则为95%),并通过选择volatile-ttl或者allkey-lru等作为驱逐策略,如非必要,避免使用noeviction,可用严格限制Redis的内存使用,以确保不会产生内存交换。

2、total_commands_processed

处理的命令数,可以通过该指标来诊断延迟。

例如,如果处理的命令激增,并且导致Redis处理不过来,那么就会导致Redis响应变慢,该指标值突然增加;或者如果正在执行一个复杂度很高的命令,导致Redis被阻塞住,那么同样会导致Redis响应变慢,该指标值下降或者停滞了。

可以设置一个脚本来定期记录total_commands_processed指标,并测量延迟。如果观测到指标相比之前有所增加,可能是突然接受了一大批命令,并且在排队等待执行,此时可能导致Redis处理不过来导致响应延迟;如果观测到指标相比之前有所减少,可能是有几个阻塞系统的慢命令在执行。

如何解决大批命令排队或者慢命令导致的延迟问题?

  • 通过使用多参数命令,如MGET,MSET,LPUSH, RPUSH等,把一批数据一次性传递给Redis,而不是循环一个一个命令的传递,这可以减少命令数量;
  • 使用pipeline,将多个命令一起发送给Redis,这样可以减少由于网络开销导致的延迟;
  • 避免使用bigkey,避免使用复杂度高的命令;

3、Latency

Latency,延迟,衡量Redis服务器响应所需的平均时间,次指标无法通过Redis info命令获得,可以通过以下命令得到:

1
2
➜  ~ redis-cli -p 6379 --latency
min: 0, max: 2, avg: 0.20 (8293 samples)

如何诊断和解决Redis延迟问题?

一旦您确定延迟是一个问题,可以采用以下措施来诊断和解决相关性能问题:

  • **使用慢日志识别慢命令:**通过查看Redis慢日志,可以快速识别超过用户指定执行时间的命令;

    • ➜  ~ redis-cli -p 6379
      127.0.0.1:6379> slowlog get
      (empty array)
      # 通过以下命令设置慢日志的阈值
      127.0.0.1:6379> config set slowlog-log-slower-than 5000
      OK
      
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14

      * **监控客户端连接:**由于Redis是单线程的,随着客户端连接数量增加,分配给每个客户端的资源百分比就会减少,导致每个客户端花费越来越多的时间等待Redis服务器执行操作和响应。监控客户端连接数很重要,因为应用程序可能无法有效关闭未使用的连接:

      * ```bash
      127.0.0.1:6379> info clients
      # Clients
      connected_clients:3
      cluster_connections:0
      maxclients:10000
      client_recent_max_input_buffer:48
      client_recent_max_output_buffer:0
      blocked_clients:0
      tracking_clients:0
      clients_in_timeout_table:0
  • **限制客户端连接:**Redis 2.6以及更高版本可以在redis.conf中或者redis-cli中配置Redis服务器的最大连接数maxclients,你应该设置maxclients为预期峰值的110~150%;

  • **改善内存管理:**需要重点监控内存是否够用。

4、Fragmentation Ratio

碎片率,可以通过mem_fragmentation_ratio指标得到内存碎片率。

mem_fragmentation_ratio = used memory rss / used memory

used_memory_rss:操作系统分配给Redis实例的内存大小,表示Redis进程占用的物理内存大小;

used_memory:Redis使用其分配器分配的内存大小。

什么时候碎片化严重?

mem_fragmentation_ratio < 1 表示Redis内存分配超出了物理内存,操作系统正在进行内存交换;

mem_fragmentation_ratio > 1 合理的指标值;

mem_fragmentation_ratio > 1.5 表示Redis消耗了实际需要物理内存的150%以上,其中50%是内存碎片率。

如果这个值超过1.5(50%)了,说明碎片化还是比较严重的,需要进行优化了。

5、Evictions

evicted_keys 指标给出了已被驱逐(删除)的key数量。

如果evicted_keys增长比较快,说明部分CPU用来回收key了。

您可以通过将 maxmemory-policy 设置为 volatile-lru 或 volatile-ttl 等选择不同的驱逐算法。

如果您的 evicted_keys 始终高于0,可能会导致命令延迟的增加,因为此时Redis除了处理客户端命令请求之外,还需要处理频繁的驱逐工作。但是驱逐并不像内存交换那样对性能具有更大的杀伤力。

如何减少Redis驱逐的影响?

这里有两种方法可以减少Redis的驱逐次数:

  • 增加maxmemory限制,但是要注意,不要让内存不足导致进行内存交换;
  • 对您的实例进行分区。

6、其他更多指标[1]

  • keyspace_misses:key值查找未命中缓存的次数,如果出现次数太多,则要考虑是否有缓存穿透问题,或者是否被恶意攻击;
  • blocked_clients:等待阻塞调用的客户端数量(BLPOP、BRPOP、BRPOPLPUSH、BLMOVE、BZPOPMIN、BZPOPMAX);
  • instantaneous_ops_per_sec:每秒处理的命令数;
  • total_commands_processed:服务器处理的命令总数;
  • total_connections_received:服务器接受的链接总数;
  • expired_stale_perc:可能已过期的key的百分比;
  • used_cpu_sys:Redis服务器消耗的系统CPU,是服务进程所有线程的消耗系统CPU之和;
  • used_cpu_sys_main_thread:Redis服务器主线程消耗的系统CPU;
  • used_cpu_user_main_thread:Redis服务器主线程消耗的用户CPU…

如何快速得到Redis服务器的性能?

Redis 包含redis-benchmark[2]模拟 N 个客户端同时发送 M 个查询执行的运行命令的实用程序。

可以通过redis-benchmark命令对Redis进行性能测试:

./redis-benchmark -c 100 -n 5000

对应为100个连接,执行5000次请求的性能结果。


以上就是Redis相关的内容,由于Redis的思维导图比较大,所以没有在文章中放完整的截图,感兴趣的朋友可以到Java架构杂谈公众号回复 Redis 获取思维导图文件。

image-20211010183402705

References


  1. INFO [section]. Retrieved from https://redis.io/commands/INFO ↩︎

  2. How fast is Redis?. Retrieved from https://redis.io/topics/benchmarks ↩︎

本文作者: 帅旋

本文链接: https://www.itzhai.com/columns/redis/monitoring-metrics.html

版权声明: 版权归作者所有,未经许可不得转载,侵权必究!联系作者请加公众号。

×
IT宅

关注公众号及时获取网站内容更新。