之前有个小伙伴在技术交流群里咨询过一个问题,我当时还给提供了点排查思路,是个典型的八股文转实战分析的案例,我觉得挺有意思,趁着中午休息简单整理出来和大家分享下,有不严谨的地方欢迎大家指出。
全连接队列溢出时,首先要查看全连接队列的状态,服务端通常使用ss命令即可查看,ss命令获取的数据又分为LISTEN状态 和非LISTEN两种状态下,通常只看LISTEN状态数据就可以。
当半连接队列或全连接队列满了时,服务器都无法接收新的连接请求,从而导致客户端无法建立连接。全连接队列 队列信息
我们先来看看他的问题,下边是他在群里对这个问题的描述,我大致的总结了一下。
第三步:客户端会返回ACK确认,等待客户端调用accept()方法将连接取出来使用;服务端收到第三次握手的ACK后标识连接成功。这种情况我们称之为队列溢出。
第一步:客户端发起SYN_SEND连接请求,服务端收到客户端发起的SYN请求后,会先将连接请求放入半连接队列;
看到这几个数值,直觉告诉我大概率是TCP请求溢出了,我给的建议是先直接调大全连接队列和半连接队列的阀值试一下效果。
TCP协议三次握手的过程,Linux内核维护了两个队列,那就存在队列被压满的时候,创建新的连接并将其添加到全连接队列,如果这时全连接队列没满,内核会把连接从半连接队列移除,即然叫队列,SYN半连接队列和accepet全连接队列。
他们有很多的 IOT 设备与服务端建立连接,当增加设备并发请求变多,TCP连接数在接近1024个时,可用TCP连接数会降到200左右并且无法建立新连接,而且分析应用服务的GC和内存情况均未发现异常。
近期评论