主体内容
- 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种场景执行:
- 数据量写入不大,AOF文件不大时,固定在每天的凌晨1-4点进行AOF持久化重写。所以容易出现这个时间点实例CPU使用率超高的现象。
- 数据量写入过大,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。