溢出OVERFLOW2未增删带翻译(全队列溢出问题排查过程)

大家好，感谢邀请，今天来为大家分享一下溢出OVERFLOW2未增删带翻译的问题，以及和全队列溢出问题排查过程的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

1.前言

本文排查的问题是经典的TCP队列溢出问题，因TCP队列问题在操作系统层面没有明显的指标异常，容易被忽略，故把排查过程分享给大家。

2.问题描述

A服务调用B服务接口超时，B服务主机IOWAIT高，具体超时情况分为两种：

A服务的请求在B服务日志中可查到，但B服务的响应时间超过了A服务的等待超时时间3S。A服务的请求在B服务日志中无法查到。3.问题分析

此种超时请求集中在很短的一段时间（通常在2分钟之内），过后便恢复正常，所以很难抓到问题现场分析原因，只能搭建测试环境，A服务持续请求B服务，在B服务主机上通过DD命令写入大量数据造成主机IOWAIT高，同时通过TCPDUMP在两端抓包分析。部分服务超时日志：

服务A：Gethttp://xxx&id=593930:net/http:requestcanceled(Client.Timeoutexceededwhileawaitingheaders)服务B:"GETxxx&id=593930HTTP/1.1"20064"-""Go-http-client/1.1""-""-"165000（单位微秒）

服务A发起请求3S后没有收到服务B响应，断开连接，服务B日志显示处理时长为0.165S，远低于3S，服务A侧看服务B的响应时间为网络传输时间、TCP队列排队时间及服务B应用程序处理时间之和，因为是内网测试，网络传输时间可以忽略，主要排查方向应为TCP队列排队时间。

4.抓包数据分析

情景1：服务A及服务B均有连接日志打印。服务A端数据包分析：09:51:43.966553000服务A发起GET请求的数据包如下：

图1：服务A发起GET请求

09:51:46.966653000服务A发起GET请求3s（即服务A设置的等待超时时长）后，因未收到服务B响应，服务A向服务B发起FIN主动断开连接。

图2：服务A等待超时主动断开连接

09:51:59.958195000服务A发起http请求16s后收到服务B的http响应报文，因服务A已主动关闭该连接，故直接回复RST。

图3:服务B16s后响应

服务B端数据包分析：09:51:44.062095000服务B收到服务A发送的http请求包。

图4：服务B收到服务A的请求

09:51:59.936169000服务B响应服务A，服务B从接收到http请求报文至响应http请求总用时约为15s多，但服务B打印的日志响应时长约为0.165s。

图5：服务B15S后响应

图6：服务B日志显示响应时间0.165s

情景2：服务A有连接日志，服务B无连接日志。服务A端数据包分析：09:51:43.973791000服务A向服务B发送一个http请求数据包，随后收到服务B重传的第二次握手的syn+ack包，超过3s未收到服务B的http响应后断开连接。

图7：服务B重传syn+ack

服务B端数据包分析：服务B重传了第二次握手的syn+ack包，收到服务A的http请求，服务B忽略，未响应，服务A等待超时后断开了连接。

图8:服务B忽略服务A请求

5.根因分析

TCP在三次握手过程中内核会维护两个队列：

半连接队列，即SYN队列全连接队列，即ACCEPT队列

图9：TCP队列

TCP三次握手过程中，第一次握手server收到client的syn后，内核会把该连接存储到半连接队列中，同时回复syn+ack给client（第二次握手），第三次握手时server收到client的ack，如果此时全连接队列未满，内核会把连接从半连接队列移除，并将其添加到accept队列，等待应用进程调用accept函数取出连接，如果全连接队列已满，内核的行为取决于内核参数tcp_abort_on_overflow：

tcp_abort_on_overflow=0，server会丢弃client的ack。tcp_abort_on_overflow=1，server会发送reset包给client。

默认值是0。情景1的抓包数据显示连接已经进入全连接队列，但是服务B日志显示的连接时间晚了15S多，说明连接在队列里等待了15S后才被应用处理。情景2的抓包数据显示全连接队列已溢出，内核根据tcp_abort_on_overflow的值为0丢弃了服务A的ack，超过了服务A的超时等待时间。结论：服务B主机在IO达到瓶颈的情况下，系统CPU时间主要消耗在等待IO响应及处理软中断上，服务B应用程序获取的CPU时间有限，无法及时调用accept函数把连接取出并处理，导致TCP全队列溢出或队列等待时间过长，超过了服务A的超时时间。

6.如何观察和调整tcp全队列

图10:TCP全队列观察方法

当连接处于listen状态时：

Recv-Q：目前全连接队列的大小Send-Q：目前全连接最大队列长度

当Recv-Q>Send-Q时表示全队列溢出，可通过执行netstat-s|grep"overflowed"命令观察溢出情况，查看累计溢出次数，如果需观察一段时间内的全队列溢出情况，建议使用监控系统采集数据，比如prometheus。

图11:TCP队列溢出监控

TCP全连接队列最大值取决于min(somaxconn,backlog)，其中：

somaxconn可通过内核参数/proc/sys/net/core/somaxconn设置，默认值是128。backlog是listen(intsockfd,intbacklog)函数中的backlog大小，Nginx默认值是511，可以通过修改配置文件设置其长度。7.结语

本次问题，因为服务对成功率要求很高，所以先通过调大服务B主机/proc/sys/net/core/somaxconn参数值及服务A的超时时间来缓解超时问题，暂时保证了接口成功率。但要从根本上解决问题，仍需解决诱因io瓶颈，因为服务B主机挂载的共享sas存储集群上有其他客户的主机偶尔io很大，影响了整个集群的性能。为解决此问题，更换为独享的ssd盘，并通过blktrace+fio分析，将io调度算法修改为noop，io性能明显提升，TCP队列溢出问题也随之解决。

本文为阿里云原创内容，未经允许不得转载。

好了，关于溢出OVERFLOW2未增删带翻译和全队列溢出问题排查过程的问题到这里结束啦，希望可以解决您的问题哈！