java最大文件描述符,文件描述符(fd)泄漏排查一篇就够了

生产多次遇到文件描述符(fd)泄露相关的问题， 文件描述符泄漏一般引起

的现象是文件句柄数(封面图)/tcp alloc(上图)增长。文章分为两部分介绍文件描述符相关内容，第一部分介绍文件描述基础知识，第二部分通过实际案例进行剖析。

一. 文件描述符相关基础知识

什么是文件描述符？

内核利用文件描述符来访问文件, 打开现存文件或新建文件(建立)时，内核会

返回一个文件描述符，读写文件也需要使用文件描述符来指定待读写的文件。所有

执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符

​

最大文件描述符介绍

系统最大文件描述符限制

sysctl -a | grep fs.file-max (查看系统最大描述符)

echo “fs.file-max=1610270” >> /etc/sysctl.conf(修改最大描述符)

sysctl -p(立即生效)

用户级最大文件描述限制

ulimit -n (查看用户最大描述符)

echo “* hard nofile 65535” >> /etc/security/limits.conf

echo “* soft nofile 65535” >> /etc/security/limits.conf

代表所有用户，支持具体用户(优先级高，不受影响)。文件修改即生效，退出

或打开新终端执行ulimit -n即看到修改效果

具体某个进程(PID)最大描述符

通过cat /proc/PID/limits | grep “Max open files”

Limit Soft Limit Hard Limit Units

Max open files 65536 65536 files

进程最大描述符受限与系统／用户级，以及进程本身相关代码程序限制，比如下面

Golang代码将进程打开的最大描述符限制为10

var rLimit syscall.Rlimit

rLimit.Cur = 10

if err := syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit); err != nil {

panic(err)

}

二. 文件描述符泄漏的实际案例

某个周末，ops同学在运维群反馈某核心业务应用文件描述符以及tcp alloc非常高，导致服务不可用(这块监控不到位)。业务架构同学为了排查相关问题具体原因保留了一台问题服务，当然咯，闲着无事，参与线上故障排查。从监控图看到文件描述符不断/tcp alloc 不断增长

首先考虑是否由于Socket连接建立以后未close导致，这类也是最容易排查，netstat显示的tcp连接数正常

netstat -tan|awk '$1~/tcp/{print $NF}'|sort|uniq -c|sort -nr

156  TIME_WAIT

141  FIN_WAIT2

80  ESTABLISHED

10  LISTEN

3 CLOSE_WAIT

2 LAST_ACK

1

2

3

4

5

6

7

ss -s 查看大量处于closed 状态

通过lsof 查看tomcat 进程(进程4730)打开的文件描述符相关详细信息，lsof -p 4730。大量Prtocol：TCP异常描述符如下图所示：

通过lsof 相关信息我们找不出具体由于某原因导致的，我们通过strace查看系统调用， 查看fd泄漏的具体原因 (抓取5分钟)

strace -f -p 4730 -T -tt -o /home/futi/strace_4730.log

-tt 在每行输出的前面，显示毫秒级别的时间

-T 显示每次系统调用所花费的时间

-v 对于某些相关调用，把完整的环境变量，文件stat结构等打出来。

-f 跟踪目标进程，以及目标进程创建的所有子进程

-e 控制要跟踪的事件和跟踪行为,比如指定要跟踪的系统调用名称

-o 把strace的输出单独写到指定的文件

-s 当系统调用的某个参数是字符串时，最多输出指定长度的内容，默认是32个字节

-p 指定要跟踪的进程pid, 要同时跟踪多个pid, 重复多次-p选项即可。

tomcate多线程应用，我们需要追踪子进程运行情况，所以-f，其它参数大家看

解析应该可以理解

/home/futi/strace_4730.log，找到strace抓取这段时间内最近泄漏的fd进行分析，通过lsof -d 49959 ，可以看到出现Prtocol：TCP异常情况。下面截一小部分内容前面有大量对fd为49959打开，关闭等操作。但从4783线程操作这个fd以后strace抓取的内容未有再使用49959这个fd，且fd 不断增大，有使用大于49959的fd，所以我们可以断定是这个fd 在这块出了问题。

从上面似乎我们找不到根本原因，《Linux环境编程：从应用到内核》有这么一段：在多线程下，可能会在fcntl调用前，就已经fork出子进程。从这点出发我们查看tomcat线程ID为4783在执行fcntl前做了哪些操作，可以看出4783线程写入了一条ERROR日志

7. lsof -d 369 可以找到fd为369对应打开的文件：/data/applogs/cat/cat_20190722.log查看具体log 如下，由于连接Cat失败导致fd泄漏(由于cat上线很久了，忽略了查看cat 日志)

[07-21 23:13:21.204] [ERROR] [ChannelManager] Error when try connecting to /host:2280

strace + lsof 能解决大部分fd泄漏的问题, 感兴趣可以公众号，定期更新后端技术

————————————————

版权声明：本文为CSDN博主「写代码的小提」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/blankti/article/details/100808475