文件句柄占用问题排查经历

记录一次文件句柄溢出的排查过程。

问题现象

部署服务器的虚拟机，文件句柄数每天都会增加，最终文件句柄数耗尽，服务无法正常工作。

排查过程

1. lsof 查看文件占用的文件句柄数

由于文件句柄数的增加，只在应用启动后开始，可以定位问题是由于应用引起。
通过【lsof -p 进程号】命令，查看进程的文件句柄占用。
发现大量的文件句柄为：

java 116023 root 7485u sock  0,7 0t0  282463093 protocol:TCPv6

这意味着文件句柄占用来自于套接字，即连接请求。

初步找出文件句柄的占用来自与请求连接。

2.查看网络连接与关闭详情

strace -t -T -f -p 进程号 -e trace=network,close -o strace.out
通过上述指令对应用的网络请求
-t ：显示时间
-T : 显示调用的耗时
-f : 跟踪由fork调用所产生的子进程
-p : 指定跟踪的进程号
trace=network,close ：跟踪与网络有关的所有系统调用和close系统调用

7360 11:06:47 accept(682, { sa_family=AF_INET6, sin6_port=htons(59787), inet_pton(AF_INET6, "::ffff:172.20.4.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 19703 <0.000060>
7360 11:06:47 getsockname(19703, { sa_family=AF_INET6, sin6_port=htons(5590), inet_pton(AF_INET6, "::ffff:172.20.4.2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 <0.000038>
7360 11:06:47 getsockname(19703, { sa_family=AF_INET6, sin6_port=htons(5590), inet_pton(AF_INET6, "::ffff:172.20.4.2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 <0.000037>
7360 11:06:47 setsockopt(19703, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000047>
...
7360 11:06:47 setsockopt(19703, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 <0.000039>
7359 11:06:48 accept(627, { sa_family=AF_INET6, sin6_port=htons(59790), inet_pton(AF_INET6, "::ffff:172.20.4.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 48246 <0.000043>
7356 11:06:48 accept(462, { sa_family=AF_INET6, sin6_port=htons(59791), inet_pton(AF_INET6, "::ffff:172.20.4.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 48382 <0.000102>
7356 11:06:48 getsockname(48382, { sa_family=AF_INET6, sin6_port=htons(9999), inet_pton(AF_INET6, "::ffff:172.20.4.2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 <0.000050>
7356 11:06:48 getsockname(48382, { sa_family=AF_INET6, sin6_port=htons(9999), inet_pton(AF_INET6, "::ffff:172.20.4.2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 <0.000063>
...
7402 11:06:51 close(19703) = 0 <0.000044>
7388 11:06:53 shutdown(48382, SHUT_RD) = 0 <0.000053>

通过【sin6_port】可以看见有两个端口5590和9999
5590最终close，进行了关闭
9999只是shutdown，半关闭，未完全关闭。
所以异常端口应该是9999

查询核心
连接最终要close

通过上面一步，就能找到连接那个端口导致的文件句柄泄露。
到这里，想一想业务逻辑，或者dbug跟踪一下，问题就不能找到了。

最终发现，由于9999端口为长连接，漏检了一些网关探测连接，导致请求方断开连接后，服务端未能感知，从而导致连接没有释放，最终导致文件句柄数溢出。

总结

• 通过lsof命令查看文件句柄类型，sock就是请求连接
• 通过strace查看应用调用的详情，找出异常端口