Redis 故障排查「连接失败问题排查和解决」带你总体分析CPU及内存的使用率高问题排查指南及方案

Posted 洛神灬殇

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis 故障排查「连接失败问题排查和解决」带你总体分析CPU及内存的使用率高问题排查指南及方案相关的知识,希望对你有一定的参考价值。

主体内容

  • Redis实例CPU使用率高问题排查和解决
  • Redis实例内存使用率高问题排查和解决

Redis实例CPU使用率高问题排查和解决

问题现象

Redis实例CPU使用率短时间内冲高。CPU过高可能会导致连接超时,影响业务。

  • 发生Redis的持久化重写操作,排查及处理措施请参考是否存在Redis的持久化重写操作。

排查QPS是否过高

客户的业务负载过重,qps过高,导致CPU被用满,排查方法请参考排查QPS是否过高。此时可以查看Info指令下的commandstats子指令进行分析和输出。分析指令执行情况。

查找并禁用高消耗命令

使用了keys等消耗资源的命令,排查及处理措施请参考查找并禁用高消耗命令。高消耗资源的命令即时间复杂度为O(N)或更高的命令,通常情况下,命令时间复杂度越高,在执行时消耗的资源越高,这会导致CPU使用率超高,容易触发主备倒换。关于各命令对应的时间复杂度信息请参见Redis官网。例如,使用了keys等消耗资源的命令,导致CPU超高,建议客户改成scan命令或者禁用keys命令。

慢查询的定位

找出CPU使用率高的具体时间段,找出高消耗的命令的慢查询。

慢查询功能会记录执行超过指定时间阈值的命令,通过分析慢查询的语句和执行时长可帮助您找出高消耗命令,具体操参见慢查询。

慢查询是Redis用于记录命令执行时间过长请求的机制。查询结果中,涉及的慢语句命令详情,请前往Redis官方网站(中文网站)查看。

慢查询结果由实例两个配置参数决定,如下:

  • slowlog-log-slower-than:如果在Redis实例的数据节点中执行一个命令,执行时间超过了slowlog-log-slower-than参数设置的阈值(单位为微秒),则会被记录到慢查询中。该参数的默认值为10000,即10ms,当Redis命令执行时间超过10ms,则生成慢查询。

  • slowlog-max-len:Redis记录的慢查询个数由slowlog-max-len参数的值决定,默认值为128个。当慢查询个数超过128时,会将旧的慢查询删除,记录新的慢查询。

读取慢查询日志

慢查询日志在内存中堆积,因此不会写入一个包含慢速命令执行信息的文件。 这使得慢查询日志非常快,你可以开启所有命令的日志记录(设置_slowlog-log-slower-than_参数值为零),但性能较低。

要读取慢查询日志,请使用SLOWLOG GET命令,此命令返回慢查询日志中的每一个条目。 可以只返回最近的N个条目,通过给命令传入一个额外的参数(例如:SLOWLOG GET 10)。

输出格式

redis 127.0.0.1:6379> slowlog get 2
1) 1) (integer) 14
   2) (integer) 1309448221
   3) (integer) 15
   4) 1) "ping"
2) 1) (integer) 13
   2) (integer) 1309448128
   3) (integer) 30
   4) 1) "slowlog"
      2) "get"
      3) "100"
结果的四个字段组成:
  • 每个慢查询条目的唯一的递增标识符。
  • 处理记录命令的unix时间戳
  • 命令执行所需的总时间,以微秒为单位。
  • 组成该命令的参数的数组。

条目的唯一ID可以用于避免慢查询条目被多次处理(例如,你也许有一个脚本使用每个新的慢查询日志条目给你发送报警邮件)。条目ID在Redis服务器运行期间绝不会被重置,仅在Redis服务重启才重置它

获取慢查询日志的当前长度

使用命令SLOWLOG LEN可以获得慢查询日志的长度。

重置慢查询日志

你可以使用命令SLOWLOG RESET来重置慢查询日志。删除后,信息将永远丢失。

除了Keys之外,Redis的高风险命令和高消耗命令:FLUSHALL、HGETALL等。

Redis的持久化重写操作也会导致CPU飙高

对于主备和集群实例,Redis实例默认开启AOF数据落盘,还有有伴随着AofRewrite的磁盘整理,AOF磁盘持久化整理一般在以下2种场景执行:

  1. 数据量写入不大,AOF文件不大时,固定在每天的凌晨1-4点进行AOF持久化重写。所以容易出现这个时间点实例CPU使用率超高的现象。

  2. 数据量写入过大,AOF文件大小超过阈值(缓存实例容量的3-5倍)时,不论当前的所处的时间,会自动触发后台AOF持久化重写。

Redis的持久化重写操作(Bgsave或Bgrewriteaof)比较消耗CPU资源,Bgsave和Bgrewriteaof会调用系统的Fork机制,造成CPU短暂时间冲高。

如果不需要用到持久化功能,建议将该功能关闭(请根据实际业务慎重操作,关闭持久化功能会导致极端故障场景下恢复时,由于没有落盘造成的数据丢失)。关闭操作:将“appendonly”修改为“no”。

Redis实例内存使用率高问题排查和解决

问题现象

Redis可提供高效的数据库服务,当内存不足时,可能导致Key频繁被逐出、响应时间上升、QPS(每秒访问次数)不稳定等问题,进而影响业务运行。由于Redis自身运行机制(主从同步、延迟释放等),内存占用率可能出现略微超过100%的情况,此为正常情况,此时内存已经写满,用户需要考虑扩容,或者清理一些无用的数据。通常情况下,当内存使用率超过95%时需要及时关注。

排查原因

  • 查询指定时段的内存使用率信息,“内存利用率”指标持续接近100%。
  • 查询内存使用率超过95%的时间段内,“已逐出的键数量”和“命令最大时延”,均呈现显著上升趋势,表明存在内存不足的问题。

Redis实例如果内存满了但是key不多,可能原因是客户端缓冲区(output buffer)占用过多的内存空间。可以在Redis-cli客户端连接实例后,执行大key扫描命令:redis-cli --bigkeys,然后执行info,查看output buffer占用情况。

bigkeys和hotkeys参数查找大Key和热Key

Redis-cli提供了bigkeys参数,能够使redis-cli以遍历的方式分析Redis实例中的所有Key,并返回Key的整体统计信息与每个数据类型中Top1的大Key,bigkeys仅能分析并输入六种数据类型(STRING、LIST、HASH、SET、ZSET、STREAM),命令示例为:redis-cli -h <实例的连接地址> -p <端口> -a <密码> --bigkeys

自Redis 4.0版本起,redis-cli提供了hotkeys参数,可以快速帮您找出业务中的热Key,该命令需要在业务实际运行期间执行,以统计运行期间的热Key。命令示例为:redis-cli -h <实例的连接地址> -p <端口> -a <密码> --hotkeys。热Key的详情可以在结果中的summary部分获取到。

优化建议:

  • string类型控制在10KB以内,hash、list、set、zset元素尽量不超过5000。

以上是关于Redis 故障排查「连接失败问题排查和解决」带你总体分析CPU及内存的使用率高问题排查指南及方案的主要内容,如果未能解决你的问题,请参考以下文章

Redis 故障排查「连接失败问题排查和解决」带你总体分析CPU及内存的使用率高问题排查指南及方案

Django连接Redis集群问题排查思路和总结

Redis无法写入故障排查过程

AD常见故障排查---运维笔记

错误记录使用 Jedis 操作 Redis 数据库报错 ( JedisConnectionException | Redis 连接超时故障排查点 | 绑定配置 | 保护模式 | 防火墙 )

Redis 忽然变慢了如何排查并解决?