运行在Linux系统上的Java程序运行了一段时间后出现"Too many open files"的异常情况。
这种情况常见于高并发访问文件系统,多线程网络连接等场景。程序经常访问的文件、socket在Linux中都是文件file,系统需要记录每个当前访问file的name、location、access authority等相关信息,这样的一个实体被称为file entry。“open files table”(图中橙色标识)存储这些file entry,以数组的形式线性管理。文件描述符(file descriptor)作为进程到open files table的指针,也就是open files table的下标索引,将每个进程与它所访问的文件关联起来了。
每个进程中都有一个file descriptor table管理当前进程所访问(open or create)的所有文件,文件描述符关联着open files table中文件的file entry。细节不表,对于open files table能容纳多少file entry。Linux系统配置open files table的文件限制,如果超过配置值,就会拒绝其它文件操作的请求,并抛出Too many open files异常。这种限制有系统级和用户级之分。
系统级:
系统级设置对所有用户有效。可通过两种方式查看系统最大文件限制
1 cat /proc/sys/fs/file-max
2 sysctl -a 查看结果中fs.file-max这项的配置数量
如果需要增加配置数量就修改/etc/sysctl.conf文件,配置fs.file-max属性,如果属性不存在就添加。
配置完成后使用sysctl -p来通知系统启用这项配置
用户级:
Linux限制每个登录用户的可连接文件数。可通过 ulimit -n来查看当前有效设置。如果想修改这个值就使用 ulimit -n 命令。
对于文件描述符增加的比例,资料推荐是以2的幂次为参考。如当前文件描述符数量是1024,可增加到2048,如果不够,可设置到4096,依此类推。
在出现Too many open files问题后,首先得找出主要原因。最大的可能是打开的文件或是socket没有正常关闭。为了定位问题是否由Java进程引起,通过Java进程号查看当前进程占用文件描述符情况:
lsof -p $java_pid 每个文件描述符的具体属性
lsof -p $java_pid | wc -l 当前Java进程file descriptor table中FD的总量
分析命令的结果,可判断问题是否由非正常释放资源所引起。
如果我们只是普通用户,只是暂时的修改ulimit -n,可以直接shell命令来修改(ulimit -n 1024000)。但是这个设置时暂时的保留!当我们退出bash后,该值恢复原值。
如果要永久修改ulimit,需要修改/etc/security/limits.conf。
vim /etc/security/limits.conf
# 添加如下的行
* soft nofile 2048
* hard nofile 2048
以下是说明:
* 代表针对所有用户
noproc 是代表最大进程数
nofile 是代表最大文件打开数
添加格式:
[username | @groupname] type resource limit
[username | @groupname]:设置需要被限制的用户名,组名前面加@和用户名区别。也可以用通配符*来做所有用户的限制。
type:有 soft,hard 和 -,soft 指的是当前系统生效的设置值。hard 表明系统中所能设定的最大值。soft 的限制不能比hard 限制高。用 - 就表明同时设置了 soft 和 hard 的值。
[Ok3w_NextPage]resource:
core - 限制内核文件的大小(kb)
date - 最大数据大小(kb)
fsize - 最大文件大小(kb)
memlock - 最大锁定内存地址空间(kb)
nofile - 打开文件的最大数目
rss - 最大持久设置大小(kb)
stack - 最大栈大小(kb)
cpu - 以分钟为单位的最多 CPU 时间
noproc - 进程的最大数目
as - 地址空间限制
maxlogins - 此用户允许登录的最大数目
实例:
username soft nofile 2048
username hard nofile 2048
@groupname soft nofile 2048
@groupname hard nofile 2048