分享

QPS过万,Redis大量连接超时解决方法

问题导读:
1、如何查看异常分布?
2、如何排查CPU使用情况?
3、如何排查GC停顿问题?
4、如何衡量网络质量和服务器稳定性?


之前负责的一个服务总是在高峰时刻和压测发生大量的redis连接超时的异常redis.clients.jedis.exceptions.JedisConnectionException,根据原有的业务规则,首先会从数据库查询,然后缓存到redis中,超时时间设置为3分钟。

并且由于业务的特性,本身未做降级、限流等处理措施,而在巅峰的QPS基本上快达到20000的样子,虽然这个现象只是单纯的一个异常,并不会导致整个主链路的流程不可用,但是我们还是要找出问题的原因并且解决。

首先我们找到负责Redis同学排查,他们告诉我Redis现在很稳定,没有问题,以前现在未来都不会出问题,出了问题肯定是你们自己的问题。

... ...

说的好有道理,我竟无力反驳,真是让人两个头一个大。

这样的话,我们就只能去找找自身的原因了。

排查思路

查看异常分布

首先根据经验,我们看看自己的服务器的情况,看下异常到底出现在哪些机器,通过监控切换到单机维度,看看异常是否均匀分布,如果分布不均匀,只是少量的host特别高,基本可以定位到出现问题的机器。

诶,这就很舒服了,这一下子就找到了问题,只有几台机器异常非常高。

不过不能这样,我们继续说排查思路......

Redis情况

再次按照经验,虽然负责redis的同学说redis贼稳定巴拉巴拉,但是我们本着怀疑的态度,不能太相信他们说的话,这点很重要,特别是工作中,同学们,不要别人说啥你就信啥,要本着柯南的精神,发生命案的时候每个人都是犯罪嫌疑人,当然你要排除自己,坚定不移的相信这肯定不是我的锅!

好了,我们看看redis集群是否有节点负载过高,比如以常规经验看来的80%可以作为一个临界值。

如果有一个或少量节点超过,则说明可能存在热key问题,如果大部分节点都超过,则说明存在redis整体压力大问题。

另外可以看看是否有慢请求的情况,如果有慢请求,并且时间发生问题的时间匹配,那么可能是存在大key的问题。

嗯... ...

redis同学说的没错,redis稳如老狗。

CPU

我们假设自己还是很无助,还是没发现问题在哪儿,别急,接着找找别人的原因,看看CPU咋样,可能运维偷偷滴给我们把机器配置给整差了。

我们看看CPU使用率多高,是不是超过80%了,还是根据经验,我们之前的服务一般高峰能达到60%就不错了。

再看看CPU是不是存在限流,或者存在密集的限流、长时间的限流。

如果存在这些现象,应该就是运维的锅,给我们机器资源不够啊。

GC停顿

得嘞,运维这次没作死。

再看看GC咋样。

频繁的GC、GC耗时过长都会让线程无法及时读取redis响应。

这个数字怎么判断呢?

通常,我们可以这样计算,再次按照我们一塌糊涂的经验,每分钟GC总时长/60s/每分钟GC个数,如果达到ms级了,对redis读写延迟的影响就会很明显。

为了稳一手,我们也要对比下和历史监控级别是否差不多一致。

好了,打扰了,我们继续。

网络

网络这块我们主要看TCP重传率,这个基本在大点的公司都有这块监控。

  1.     TCP重传率=单位时间内TCP重传包数量/TCP发包总数
复制代码

我们可以把TCP重传率视为网络质量和服务器稳定性的一个只要衡量指标。

还是根据我们的经验,这个TCP重传率越低越好,越低代表我们的网络越好,如果TCP重传率保持在0.02%(以自己的实际情况为准)以上,或者突增,就可以怀疑是不是网络问题了。

2021-04-27_194500.jpg

最后

根据一系列的骚操作,我们根据定位到的机器然后排查了一堆情况,最终定位到是网络问题,有单独的几台机器在高峰时期TCP重传率贼高,最后根据运维提供的解决方案:【重启有问题的机器】,我们很顺利的就解决了这个问题。

作者:艾小仙
来源:https://mp.weixin.qq.com/s/iDU31WuVEoQB6aSo1J_o-Q

最新经典文章,欢迎关注公众号


已有(2)人评论

跳转到指定楼层
baifuwa 发表于 2021-4-28 08:58:04
重启就解决了?
回复

使用道具 举报

crayfish 发表于 2021-5-6 14:04:51

重启就解决了?
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /5 下一条