线上问题排查实例分析|关于网络超时

相较于日常的编程工作,线上问题排查往往是较为低频但重要的场景。尽管我们可能不常遇到,但每当这时,其紧迫性和重要性都使得我们必须迅速、准确地找出解决方案。因此,对技术人来说,培养有效的线上问题排查思路和方法至关重要。

为应对这种不确定性,我们需要在平时就关注和学习他人的排查经验与技巧,以便在需要时能够迅速调用这些储备,冷静应对。滴滴技术公众号将定期分享线上问题排查的相关文章,以期为读者提供一些解决问题的思路和实战案例,期待通过这些内容与大家进行深入的交流和探讨。

最近生产环境出现了两起奇怪的超时问题,一个是调用 redis 导致程序夯住300s左右,另一个是上游请求频繁超时(120ms~200ms之间),两个问题都发生在同一个服务上(golang程序),并且比较典型,所以在这里一起说下,希望对大家有借鉴意义。

Redis超时300s

一天业务RD同学突然发现线上一个新增接口偶现耗时300s+,我第一反应觉得可能又是程序里哪里有 bug,因为最近在给各个项目做体检,发现了很多类似问题,但 RD 同学反馈说通过日志看应该是调用 redis 夯住了,而且新增的业务逻辑确实新增了 redis 调用,但调用 redis 的 sdk 没有设置超时,所以觉得应该是 redis 或者网络抖动导致的,但300s还是让人无法理解,就算是抖动也不至于耗时300s+,redis 应该也会主动关闭连接,所以我们开始了问题排查。

1、首先排除是不是抖动,通过跟 redis 同学反复确认,他们的耗时处理都是在1ms以下,没发现长时间的耗时,又跟运维确认是否有网络抖动,运维反馈说机房10G网卡确实会出现偶尔的丢包现象,正在换100G网卡,但偶尔丢包会有重试,不会导致耗时这么长,所以排除了丢包问题(后面发现确实是丢包,没想到的是重试包也丢了)。

2、接着开始怀疑是我们使用的 sdk 有问题,因为以前发生过sdk导致的耗时问题,于是升级到了最新的库,同时加了更详细的 debug 日志,最后发现是 read的时候阻塞了,并最终收到了 RST 包,日志如下,所以基本排除了 pkg 的问题。 

connection reset by peer

3、这个时候大家开始了各种猜测:丢包、内核参数问题、Gateway 升级等等,同时也发现了更多的现象,比如偶尔出现几台机器同时耗时长的问题,其他部门的同学也反馈有300s耗时问题,同样是调用 redis,种种猜测之后还是决定抓包来看,由于复现的概率比较低,也没有规律,同时机器也比较多,抓包成本比较大,所以抓包耗费了很长时间,直到线上复现了超时问题。

4、redis proxy 机器数比较少相对好抓,client 端机器比较多,所以只抓了个别机器,最终抓到问题流量如下:

线上问题排查实例分析|关于网络超时_第1张图片

通过分析流量,我们发现 client 端一直在超时重试(Retransmission,这里遵循以TCP_RTO_MIN=HZ/5 = 200ms 开始的退避算法,200ms、400ms,800...),一直到最后服务端返回了 RST,这个正好印证了第二步日志中报的错误"connection reset by peer",在这期间,server端一直没有返回 ack,但在09:18:12的时候收到了server端发送的 keep-alive 包,也叫 tcp 探活包,时间刚好是从上一次请求后的75s(redis 确认设置了 keep-alive 时间是75s),client 也发送了 keep-alive 的 ack 包,理论上来说 server 端在75s内就不会再发送探活包了,但实际后面依然在发送,直到RST结束,所以从整个流量来看,好像 redis 端收不到包,但 client 可以收到 redis 的包。同一时间redis也同步开启了抓包,但并没收到我们发送的PSH包,接下来开始一步步验证猜测。

5、因为调用方式采用的VIP,VIP指向 Gateway,但 Gateway 都是公用的,流量很大,很难抓包,所以我们通过排除法,选择直连真实ip,绕过 Gateway,通过两天观察,类似的问题消失了,所以基本就定位到是 Gateway 问题,但运维同学反复确认过 Gateway 确实没发现啥问题,而且也没有其他业务反馈类似的问题(有3000多个VIP),再此陷入停滞。

6、既然已经通过排除定位到 Gateway 问题,那就看下 Gateway 到底怎么实现的,看是不是有转机,开始跟系统运维同学确认实现方式:

线上问题排查实例分析|关于网络超时_第2张图片

“fullnat模式”,一下感觉有了转机,fullnat相对nat模式有一个重要的区别就是session表从一个变成了两个(session表用作关联客户端和服务端的ip:port),一个IN一个OUT,如果IN的表丢失了,而OUT表正常,就有可能出现上述抓包的问题流量——client 能收到 server 包,server 收不到 client 包。

通过跟系统运维同学确认,确实有可能会出现,运维同学也开始了 Gateway 的验证和排查,直接贴运维同学的排查过程,更专业一些: 

线上问题排查实例分析|关于网络超时_第3张图片

经过不断推断和验证,终于得到了路由器厂商的确认。

5d9067c70783ee2e665f87d2f87d3877.png

超时思考

到此算整个事件的结束,实际情况远比描述的复杂,也引发了我关于超时的思考:

关于超时的问题,是不计成本的增强基础设施建设吗?

基础设施当然会尽量提高自身的稳定性和可用性,但一旦达到一个限值,再提升,可能就需要付出几倍甚至上百倍的成本,比如丢包率从0.02%降低到0.01%,提升0.01%的成本可能比实现0%到99.98%的成本还要大,100%更是永远达不到,但任何一个系统都不是只有一层,如果在上层加一次超时重试,这种低成本的操作往往可以达到惊人的效果,还是以刚才的例子说明,0.02%的丢包率,如果加一次重试可以降低到0.000004%,成功率一下从99.98%提升到99.999996%,如果一次重试不够可以再加一次。

如果加重试造成雪崩怎么办?

有一种观点是不要在下游加重试,统一从最上游加一次重试就行了,这种观点无非是担心中间链路有突发流量,会导致下游雪崩,比如网络抖动导致大规模重试。

但这种观点忽略了更重要的问题,如果说都通过最上游"端"来重试,那下游任何一个抖动导致的超时,都有可能导致整个链路所有服务被重试,到时候就不是一个服务雪崩,而是整个链路雪崩了,其实解决雪崩的问题不应该是通过减少重试次数来缓解,而是通过限流和熔断,对限流来说,越上层限流越好,而对于重试,是越下层重试越好。

那到底该设置多少超时时间和重试次数呢?

其实这两个数是有互相配合的,举个例子大家就明白了,比如我调用下游的成功率要达到五个9,调用下游的耗时98分位是20ms,那如果我设置超时时间20ms就意味着有2%的概率失败,那加一次重试可以降低到0.04%,可用性达到99.96%,不满足需求,那就再加一次重试,可用性达到99.9992%,但如果超时次数太多对上下游压力也会比较大,所以最好不要超过3次,如果重试次数确定了,那就可以通过提高超时时间来保证成功率,比如设置成99分位的耗时或者更高,但最理想的方案还是依据SLA,来确定超时时间和重试次数。

你可能感兴趣的:(网络)