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

Posted 2023-02-15

主体内容

• 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。