天河做网站要多少钱,建立网站预算,网站建设托管模式,wordpress去除 版权信息简介#xff1a;记一次TCP全队列溢出问题排查过程1. 前言本文排查的问题是经典的TCP队列溢出问题#xff0c;因TCP队列问题在操作系统层面没有明显的指标异常#xff0c;容易被忽略#xff0c;故把排查过程分享给大家。2. 问题描述A服务调用B服务接口超时#xff0c;B服务…简介记一次TCP全队列溢出问题排查过程1. 前言本文排查的问题是经典的TCP队列溢出问题因TCP队列问题在操作系统层面没有明显的指标异常容易被忽略故把排查过程分享给大家。2. 问题描述A服务调用B服务接口超时B服务主机IOWAIT高具体超时情况分为两种A服务的请求在B服务日志中可查到但B服务的响应时间超过了A服务的等待超时时间3S。A服务的请求在B服务日志中无法查到。3. 问题分析此种超时请求集中在很短的一段时间通常在2分钟之内过后便恢复正常所以很难抓到问题现场分析原因只能搭建测试环境A服务持续请求B服务在B服务主机上通过DD命令写入大量数据造成主机IOWAIT高同时通过TCPDUMP在两端抓包分析。部分服务超时日志服务AGet http://xxxid593930: net/http: request canceled (Client.Timeout exceeded while awaiting headers)服务B: GET xxxid593930 HTTP/1.1 200 64 - 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的请求9: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重传的第二次握手的synack包超过3s未收到服务B的http响应后断开连接。图7服务B重传synack服务B端数据包分析服务B重传了第二次握手的synack包收到服务A的http请求服务B忽略未响应服务A等待超时后断开了连接。图8: 服务B忽略服务A请求5. 根因分析TCP在三次握手过程中内核会维护两个队列半连接队列即SYN队列全连接队列即ACCEPT队列图9TCP队列TCP三次握手过程中第一次握手server收到client的syn后内核会把该连接存储到半连接队列中同时回复synack给client第二次握手第三次握手时server收到client的ack如果此时全连接队列未满内核会把连接从半连接队列移除并将其添加到 accept 队列等待应用进程调用 accept 函数取出连接如果全连接队列已满内核的行为取决于内核参数tcp_abort_on_overflowtcp_abort_on_overflow0server会丢弃client的ack。tcp_abort_on_overflow1server 会发送 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(int sockfd, int backlog) 函数中的 backlog 大小Nginx 默认值是 511可以通过修改配置文件设置其长度。7. 结语本次问题因为服务对成功率要求很高所以先通过调大服务B主机/proc/sys/net/core/somaxconn参数值及服务A的超时时间来缓解超时问题暂时保证了接口成功率。但要从根本上解决问题仍需解决诱因io瓶颈因为服务B主机挂载的共享sas存储集群上有其他客户的主机偶尔io很大影响了整个集群的性能。为解决此问题更换为独享的ssd盘并通过blktracefio分析将io调度算法修改为noopio性能明显提升TCP队列溢出问题也随之解决。作者陈立华原文链接 本文为阿里云原创内容未经允许不得转载