摘要:问题线上已经运行很久的一个阿里云节点集群版经常会报偏高,经确认后发现只有节点偏高,且是其他节点的倍以上,即大部分节点的占用率在到,大约是,问题节点的占用率超过,是。
问题
线上已经运行很久的一个 Redis (阿里云64节点集群版)经常会报 CPU 偏高,经确认后发现只有 13 节点 CPU 偏高,且是其他节点的 3 倍以上,即大部分节点的 CPU 占用率在 20% 到 30%,QPS 大约是 7000,问题节点的 CPU 占用率超过 80%,QPS 是 27000。
排查问题 初次定位我们首先怀疑是大 key 问题引起的,于是使用 monitor 命令在业务低峰时进行了 monitor,发现某个 类型为 hash 的 key 拆分了100片,每个 hash 的长度大约是 30 万。我们观察了这 100 个 key,在每个节点分布的比较均匀,不应该引起如此严重的偏移问题。
所以结论是该节点的 CPU 偏高不是由于大 key 问题引起的。
再次排查通过阿里云的 imonitor 命令,我对指定的节点进行了监听,并将结果保存为文本文件进行分析。
用 telnet 命令连接到阿里云的 Redis Server Cluster,在 telnet 中执行
imonitor 13
将结果保存为 redis-13.txt。
对结果进行分析
cat redis-13.txt | grep -o -E "1561806d+" | sort | uniq -c
结果为
可以看出该节点的 QPS 大概为 7000 多,远不及监控上的 27000。
因此,我们确定是阿里云的监控上对应的节点和 imonitor 的节点不对应。
发现这个问题后,我们尝试用 iinfo 命令找出来 CPU 比较高的节点。
#遍历每个节点 for i in {0..63} do redis-cli -h $host -a iinfo $i CPU done
通过该方法找到 5 节点的 CPU 显著高于其他节点。
再次使用 imonitor 命令获取该节点的 QPS:
cat redis-5.txt | grep -o -E "1561807d+" | sort | uniq -c
QPS 为 28000 左右,符合监控曲线。
然后我们通过使用 redis-faina 分析 Monitor 的结果。
首先要对结果进行处理,将 imonitor 接收到的每行开头的 "+" 号去掉,执行命令
sed -i "" "s/+//g" redis-5.txt
然后使用 redis-faina 分析结果,执行命令
python redis-faina.py redis-5.txt
得出来访问量较高的命令,发现有一个 hget 命令的 key 和 field 明显写反了,且 QPS 很高,正是这个 key 导致了 CPU 和 miss 曲线的升高。
我们在代码库中查找出问题的 key,逐行排查,发现在一个项目中确实存在 key field 写反的情况,于是通知了开发者进行修改。
第二天开发者修改了代码并进行了发布之后,曾经偏高的 CPU 节点稳定如他,问题终于算得到了解决。
结论imonitor 命令和阿里云后台的监控的节点不一致,导致问题迟迟未被发现(阿里云反馈仅在早期的 Redis 集群中有该现象,新版的 Redis 集群都是对应的)。
使用 imonitor 和 redis-faina 一起,可以方便地排查 redis 大 key 和热 key。
具体问题要具体分析,不能解决问题的时候要变通思路,通过各种方法去尝试解决问题。
本文首发于本人博客 记一次解决线上 Redis 集群单节点 CPU 偏高问题,非本人授权请勿转载。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/37290.html
摘要:哨兵是社区版本推出的原生高可用解决方案,部署架构主要包括两部分集群和数据集群,其中集群是由若干节点组成的分布式集群。自研推荐推荐自研的高可用解决方案,主要体现在配置中心故障探测和的处理机制上,通常需要根据企业业务的实际线上环境来定制化。 最近很多朋友向我咨询关于高可用的方案的优缺点以及如何选择合适的方案线上使用,刚好最近在给宜人贷,光大银行做企业内训的时候也详细讲过,这里我再整理发出来...
摘要:哨兵是社区版本推出的原生高可用解决方案,部署架构主要包括两部分集群和数据集群,其中集群是由若干节点组成的分布式集群。自研推荐推荐自研的高可用解决方案,主要体现在配置中心故障探测和的处理机制上,通常需要根据企业业务的实际线上环境来定制化。 最近很多朋友向我咨询关于高可用的方案的优缺点以及如何选择合适的方案线上使用,刚好最近在给宜人贷,光大银行做企业内训的时候也详细讲过,这里我再整理发出来...
摘要:个推专注为开发者们提供消息推送服务多年。这部分数据存储在个推集群,整个集群包括主从共百余个实例,的数量在亿级别,存储空间在级别,带来了一定的维护成本和运维挑战。灰度上线流程个推在离线消息列表存储这项业务中使用了较大规模的集群。 个推专注为开发者们提供消息推送服务多年。通过个推SDK,手机终端与服务器建立长连接,维持在线状态。然而在网络异常等情况下,消息无法实时送达到终端用户,因而推送服...
摘要:个推专注为开发者们提供消息推送服务多年。这部分数据存储在个推集群,整个集群包括主从共百余个实例,的数量在亿级别,存储空间在级别,带来了一定的维护成本和运维挑战。灰度上线流程个推在离线消息列表存储这项业务中使用了较大规模的集群。 个推专注为开发者们提供消息推送服务多年。通过个推SDK,手机终端与服务器建立长连接,维持在线状态。然而在网络异常等情况下,消息无法实时送达到终端用户,因而推送服...
摘要:个推专注为开发者们提供消息推送服务多年。这部分数据存储在个推集群,整个集群包括主从共百余个实例,的数量在亿级别,存储空间在级别,带来了一定的维护成本和运维挑战。灰度上线流程个推在离线消息列表存储这项业务中使用了较大规模的集群。 个推专注为开发者们提供消息推送服务多年。通过个推SDK,手机终端与服务器建立长连接,维持在线状态。然而在网络异常等情况下,消息无法实时送达到终端用户,因而推送服...
阅读 1227·2021-11-12 10:35
阅读 1408·2021-08-03 14:02
阅读 2431·2019-08-30 15:55
阅读 1860·2019-08-30 15:54
阅读 584·2019-08-30 14:01
阅读 2280·2019-08-29 17:07
阅读 2118·2019-08-26 18:37
阅读 2838·2019-08-26 16:51