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 failed
java.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

在这里插入图片描述

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

基本上这个很少遇到。
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服务,请排查程序,否则只是治标不治本

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐