一、背景
因为这段时间出现了一些redis cpu飙升的问题,所以总结了一些排查和解决的办法
二、产生原因和解决思路
主要产生原因有以下几点:
1.大量慢日志:
排查: 可根据以下三篇文档排查
慢日志相关:
https://blog.youkuaiyun.com/line_on_database/article/details/124098647
python收集慢日志:
https://blog.youkuaiyun.com/line_on_database/article/details/124118407
大key分析:
https://blog.youkuaiyun.com/line_on_database/article/details/115702487
解决思路:
- 业务逻辑上更改慢查询语句
- 因为大key产生的慢查询则拆分大key
- 如果是cluster可以选择增加分片
2.高频的排序集相关的操作
排查方法:
- 2.1 查看monitor监控,观测哪些命令最多,观测cpu飙升阶段哪些命令的数量飙升
redis-cli -h monitor > a.txt
ps: 如果monitor被重命名了可以采用如下方式获取
timeout 50 nc 127.0.0.1 6379 > redis.monitor
auth ****
MONITOR*** # monitor重命名的命令
- 2.2 观测info中的命令数量,是否有哪些命令量飙升
info commandstats
# 官网地址:https://redis.io/commands/info/
# calls: 到达命令执行(未拒绝)的调用次数
# usec: 这些命令消耗的总 CPU 时间
# usec_per_call:每次命令执行消耗的平均 CPU
解决: 从程序侧观察是否无用的命令太多,基于排序集的命令比较耗cpu,如果是针对多个key的高频排序集访问,只能从程序处降低该种命令的频率,逻辑优化,增加分片可能效果不大