Redis超时排查的示例分析


您的位置:首页>产品资讯> 内容正文

Redis超时排查的示例分析

这篇文章给大家分享的是有关Redis超时排查的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。

前两天的工作中,突然收到告警,提示 Redis 挂了,同时大群也在说某某 Redis 连接超时了。当初以为是有大问题,谁知道它过了一会儿就恢复了。那个时候,我登上服务器,查看监控。第一时间看看 QPS:

Redis超时排查的示例分析  

可以看到 QPS 并不高,但是中间有段时间没取到数据是怎么回事?那么继续看看 Redis 的 cpu 使用率:

Redis超时排查的示例分析  

可以看到 cpu 已经饱和,这也就能解释为何断图了,因为 redis 是单线程,在使用 cpu 100% 以后,就无法处理其他的命令了,zabbix 也就无法执行 info 命令取 qps 了。那么已经知道是 cpu 使用饱和造成的问题,那么到底是什么原因呢?那么继续查看,cpu 使用高的这段时间有没有慢日志:

Redis超时排查的示例分析  

好像也不是导致 cpu 高的凶手,这就难排查了,这个实例是 1 主 1 从。那么我看看从库的 cpu 使用情况看看:

Redis超时排查的示例分析  

卧槽,怎么回事,从库没有使用的怎么 cpu 也用到了 74%?这不科学啊?管他的,看看从库有没有慢日志:

Redis超时排查的示例分析  

卧槽,怎么回事?从库没人使用啊。看看是否只读:

127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103> 
 

看来是只读的,这把我给整懵了。最后突然想到是主库在这个点有 big key 过期,而主库过期 key 操作慢是不会记录慢日志的,从库的 key 过期是由主库发起 DEL 指令删除的。这时从库就会记录慢日志,从上面慢日志可以看到这些 DEL 操作最大的 335ms,怪不得会有应用连接超时的。

再使用命令 info commandstats 看看:

Redis超时排查的示例分析  


感谢各位的阅读!关于“Redis超时排查的示例分析”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!

发布时间:2022-09-07

统计代码