1 问题场景与现象

最近线上微服务出现问题，后台日志报错:打开的文件过多(Too many open files)

 2021-02-26 22:25:27.811 [http-nio-8841-Acceptor] ERROR org.apache.tomcat.util.net.Acceptor - Socket accept failedbrjava.io.IOException: 打开的文件过多 at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)   at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)    at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:463)    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:73)    at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:95)    at java.lang.Thread.run(Thread.java:748)

表象就是服务建立不了新的socket连接，服务无法正常使用。

2 产生原因（参考网络）

这个问题经常在Linux上出现，而且常见于高并发访问文件系统、多线程网络连接等场景。之所以出现这个问题，大多数情况是你的程序没有正常关闭一些资源引起的。

在Linux系统中，目录、字符设备、块设备、套接字、打印机等都被抽象成了文件，即通常所说的“一切皆文件”。程序操作这些文件时，系统就需要记录每个当前访问file的name、location、access authority等相关信息，这样一个实体被称为file entry。这些实体被记录在open files table中，Linux系统配置了open files table中能容纳多少file entry。如果超过这个配置值，则Linux就会拒绝其他文件操作的请求，并抛出Too many open files。

那么由上可知，产生Too many open files一般有四种可能：

单个进程打开文件句柄数过多

1 通过 ulimit -a 查看单进程可以打开的最大文件句柄数。

可以看到open files默认值是1024。

2 通过 lsof -p ${pid} | wc -l 查看单个进程实际打开的文件句柄数。（需要安装yum -y install lsof）

3 如果单个进程实际打开文件句柄数超过最大句柄数，则会出现Too many open files。

4 一般产生原因为：socket创建过多，IO流操作、数据库连接未关闭等等。

5 子进程默认继承父进程的限制（即进程和父进程打开的文件句柄数单独计算）

6 临时修改用户可打开的文件句柄数（这里主要是因为控制设置是通过用户来设置，实际上控制的是进程的文件句柄数）

使用命令 ulimit -n 2048 修改允许打开的文件数，这种设置方法在重启后会还原为默认值

ulimit -n命令非root用户只能设置到4096。

7 通过修改系统配置文件，永久生效。

#打开文件vi /etc/security/limits.conf#在最后加入* soft nofile 65535* hard nofile 65535

也可以加入* - nofile 65535生效

最前的 * 表示所有用户，可根据需要设置某一用户

注意"nofile"项有两个可能的限制措施。就是项下的hard和soft。必须对这两种限制进行设定，方可失效。 如果使用"-"字符设定, 则hard和soft设定会同时被设定。

8 动态修改进程的限制

通过prlimit --pid ${pid} --nofile=2048:2048

操作系统打开的文件句柄数过多

整个操作系统可以打开的文件句柄数是有限的，受内核参数"fs.file-max"确定。如果所有进程加起来超过了

1 通过命令cat /proc/sys/fs/file-max或者sysctl -a来查看fs.file-max的配置数量

2 临时改动：sysctl -w [变量名]=[值]

3 永久改动：修改配置文件/etc/sysctl.conf,如果文件中没有"fs.file-max"属性，则添加。设置完成后，使用sysctl -p来加载系统参数，在不指定文件位置的情况下，默认会从/etc/sysctl.conf文件中加载。systemd对该进程进行了限制

该场景仅针对被systemd管理的进程（也就是可以通过systemctl来控制的进程）生效，可以通过修改该进程的service文件（通常在 /etc/systemd/system/ 目录下），在[Service]下面添加"LimitNOFILE=20480000"来实现，修改完成之后需要执行"systemctl daemon-reload"来使该配置生效。inotify达到上限

inotify是linux提供的一种监控机制，可以监控文件系统的变化。该机制受到2个内核参数的影响："fs.inotify.max_user_instances"和"fs.inotify.max_user_watches"，其中"fs.inotify.max_user_instances"表示每个用户最多可以创建的inotify instances数量上限，"fs.inotify.max_user_watches"表示么个用户同时可以添加的watch数目，当出现too many open files问题而上面三种方法都无法解决时，可以尝试通过修改这2个内核参数来生效。修改方法是修改/etc/sysctl.conf文件，修改这2个内核参数，并执行sysctl -p。3 解决方案

由以上产生原因可分析得知，一是可以修改系统的配置信息；另外一个是从程序层面解决。

3.1 修改配置文件3.1.1 单个进程打开文件句柄数过多

通常情况下，我们遇到的问题都是"单个进程打开文件句柄数过多"

1 通过ulimit -a查看当前设置的单进程最大打开句柄数

2 通过lsof -p ${pid} | wc -l查看单个进程实际打开的文件句柄数。（需要安装yum -y install lsof），判断是不是已经接近允许的最大句柄数。

3 如果已经接近等于允许的最大句柄数,则通过临时修改与永久改动扩大单进程最大打开句柄数

 #临时修改 ulimit -n 65535

通过修改系统配置文件，永久生效。

#打开文件vi /etc/security/limits.conf#在最后加入* soft nofile 65535* hard nofile 65535

基本上这个很少遇到。

1 通过命令cat /proc/sys/fs/file-max或者sysctl -a来查看fs.file-max的配置数量

2 临时改动：sysctl -w [变量名]=[值]

3 永久改动：修改配置文件/etc/sysctl.conf,如果文件中没有"fs.file-max"属性，则添加。设置完成后，使用sysctl -p来加载系统参数，在不指定文件位置的情况下，默认会从/etc/sysctl.conf文件中加载。

3.1.3 systemd对该进程进行了限制与inotify达到上限

在以上2种方法都无效后，考虑这2种情况的解决方案

1 可以通过修改该进程的service文件（通常在/etc/systemd/system/目录下），在[Service]下面添加"LimitNOFILE=20480000"来实现，修改完成之后需要执行"systemctl daemon-reload"来使该配置生效

2 可以尝试通过修改这"fs.inotify.max_user_instances"和"fs.inotify.max_user_watches"这2个内核参数来生效。修改方法是修改/etc/sysctl.conf文件，修改这2个内核参数，并执行sysctl -p。

3.2 排查程序

一般情况下，1024个句柄数应该够程序使用（如果不是socket服务），如果出现Too many open files错误，首先考虑是不是程序出了问题，比如IO流，数据库连接池及各种其它的连接池等。若是socket服务，建议修改配置文件扩大打开文件句柄数。

总结Too many open files是liunx常见问题之一有四种原因会产生这个问题（单个进程打开文件句柄数过多、操作系统打开的文件句柄数过多、systemd对该进程进行了限制、inotify达到上限）一般扩大单个进程打开文件句柄数即可解决问题如果你的程序不是socket服务，请排查程序，否则只是治标不治本