之前面试 曾经被问到 CLOSE_WAIT 状态意味这什么(服务端收到FIN 包后 还没有close fd,存在fd 泄漏的风险)
问题现象:
代理报错 too many open files, ulimit 设置为100W(/proc/pid/limits),使用ss 命令才几千,lsof 有很多 socket(不显示 ESTAB 等TCP 状态,仅显示 SOCK),查看进程 /proc/pid/fd/ 确实有100w (大量不显示状态的socket), 达到了ulimit 上限.
经过排查,代理由于请求hang 住, 没有close accept 的socket,出现了 fd 泄漏的问题,本地可以复现。
问题是:为什么ss 不显示这些tcp 的状态:CLOSE_WAIT
使用bcc 工具的 tcplife, tcpstates 工具(-L port)发现 连接居然从 CLOSE_WAIT =》 CLOSE 状态,且时间是15秒以后。
/usr/share/bcc/tools/tcpstates -L xxx
SKADDR C-PID C-COMM LADDR LPORT RADDR RPORT OLDSTATE -> NEWSTATE MS
ffff8801c5c5a340 2558058 curl ::ffff:127.0.0.1 xxx ::ffff:127.0.0.1 46124 ESTABLISHED -> CLOSE_WAIT 0.000
ffff8801c5c5a340 0 swapper/1 ::ffff:127.0.0.1 xxx ::ffff:127.0.0.1 46124 CLOSE_WAIT -> CLOSE 15004.867
既然应用层没有 close fd,那么肯定是内核干的事情了,在网上搜索了 TCP_KEEPALIVE 可以。
抓包:这里很明显 服务端发送了一个keep-alive 包,客户端RST ,内核回收连接。
tcpdump -nnvvv -A -s0 -i lo -w tcp.pacp
为什么是15秒呢? setKeepAlivePeriod default golang 自带 accept 会设置。如果fint_timeout(TIME_WAIT) 少于这个值,回收了fd,此时对收到的包进行rst了。
内核完成了连接清理,所以ss 已经看不到ESTAB 或者CLOSE_WAIT, 只剩下fd 目录下一堆 未 关闭的 socket 文件描述符