tcp协议在定位中的应用(2)

 

  上一篇文章说到还是产生 accpet open too many files的错误。

  这个一般是通过修改ulimit就可以了,但是修改这个参数有一个误区,就是生效的时机。虽然你登录终端看ulimit -a看到open files连接数是够大了,但是对于app运行的环境并不一定是这个数目。具体可以通过cat /proc/{app自己的pid}/limits来确认真实的limits。

  对于当时情况是:ulimit 修改后没有对用户进程产生作用。经过不停排除发现进程是由supervisor来启动,先找到supervisor,修改superv里面的fd值,发现还是不能生效。发现supervisord又是由 systemctrl启动,在systemtrl的配置文件里面修改了最大文件数,最后才生效。

  通过修改好limit open fils这一项,后续再也没有出现open too many files的错误了。

       当时在看出现open too many files的时候,发现netstat -apnt 查看,发现有很多close_wait。这个是如何产生的?

       首先我们理解accept: open too many files中的open too many files是句柄数目的限制。那么accept是什么?

       tcp连接中,分为两种连接,半连接和全连接。全连接的也就是 ESTABLISHED 建立的连接,也就是accept操作建立的连接。accpet队列就是全连接队列。这个队列的大小由两个参数的最小值决定,一个是系统级别,另一个是独立应用级别的。

  • 全连接队列的大小:min(backlog, /proc/sys/net/core/somaxconn),意思是取backlog 与 somaxconn 两值的最小值,net.core.somaxconn 定义了系统级别的全连接队列最大长度,而 backlog 只是应用层传入的参数,所以 backlog 值尽量小于net.core.somaxconn;

  • net.core.somaxconn(内核态参数,系统中每一个端口最大的监听队列的长度);

  • net.core.netdev_max_backlog(每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目);

  • ServerSocket(int port, int backlog) 代码中的backlog参数;

  • 文件句柄;

  • net.ipv4.tcp_abort_on_overflow = 0,此值为 0 表示握手到第三步时全连接队列满时则扔掉 client 发过来的 ACK,此值为 1 则说明握手到第三步时全连接队列满时则返回 reset 给客户端。

  连接的数量有一个地方需要澄清,客户端进入了连接状态,但是服务端不一定进入了连接状态,根据状态转移图:有一个步骤的时间差,就是收到客户端的ack,后服务端才认为自己正式建立了连接。所以连接数,在客户端与服务端之间有一个时间差。

 tcp协议在定位中的应用(2)

 

 

  实际中,发现服务端建立连接,但是由于服务端各种原因,自己可以让服务睡眠时间久点。accept客户端的连接请求慢点,导致最终accept队列满了,一般阈值是(128+1)个连接。然后客户端超时,请求关闭还没有进入到全连接队列的连接,SYN_RECV 状态持续一段时间后会消失。服务端对于客户端的关闭请求回复了ack,进入了close_wait, 但是服务端的连接还在被accept阻塞,所以会一直处于close_wait的状态中不释放。   最终要把close_wait释放的手段,一种程序内部调用close关闭连接(需要改代码),一种是被kill掉。通过tcpdump抓包,发现这种是服务端主动发起RST报文,然后关闭了连接。        所以线上出现了close_wait问题,那么很有可能就是程序被阻塞,或者是某种情况没有close掉连接   注意,该代码没有给连接主动close掉。
package main

import (
        "log"
        "net"
        "time"
)

func main() {
        l, err := net.Listen("tcp", ":8889")
        if err != nil {
                log.Println("error listen:", err)
                return
        }
        defer l.Close()
        log.Println("listen ok")

        var i int
        for {
                time.Sleep(time.Second * 100000)
                log.Printf("%d: accept a new connection\n", i)
                if _, err := l.Accept(); err != nil {
                        log.Println("accept error:", err)
                        break
                }
                i++
                log.Printf("%d: accept a new connection\n", i)
        }
}

netstat -antp 查看

cp        0      0 192.168.0.105:8889      192.168.0.100:40088     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40100     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40102     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40090     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40098     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40092     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40096     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40094     SYN_RECV    -                    tcp        0      0 192.168.0.105:8889      192.168.0.100:40086     SYN_RECV    -                    tcp6     129      0 :::8889                 :::*                    LISTEN      37482/server         tcp6       0      0 192.168.0.105:8889      192.168.0.100:40034     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:40014     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:39844     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:40002     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:40040     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:39942     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:40022     ESTABLISHED -                    tcp6       0      0 192.168.0.105:8889      192.168.0.100:39992     ESTABLISHED -          ......   [jet@192 ~]$ sudo netstat -lpnt  | grep 8889 tcp6     129      0 :::8889                 :::*                    LISTEN      37482/server       客户端: [jet@192 ~]$ sudo netstat -antp | grep client | wc -l 129   服务端: jet@192 ~]$ sudo sysctl -a | grep conn net.core.somaxconn = 128     kill 掉客户端请求后,就发现服务端的状态进入了close_wait,因为kill掉客户端后,客户端会发出关闭连接请求, SYN_RECV    状态请求在半连接队列里面,后面会消失: [jet@192 ~]$ sudo netstat -antp | grep client  [jet@192 ~]$  服务端 [jet@192 ~]$ sudo netstat -anpt  | grep 8889 | grep CLOSE_WAIT | wc -l 129

 

上一篇:c – Mac OS X上的CGAL链接错误


下一篇:2020年5月31行情分析