linux too many open files 解决方法

1、增大允许打开的文件数——命令方式
ulimit -n 2048
这样就可以把当前用户的最大允许打开文件数量设置为2048了，但这种设置方法在重启后会还原为默认值。
ulimit -n命令非root用户只能设置到4096。
想要设置到更大需要sudo权限或者root用户。

2、增大允许打开的文件数——修改系统配置文件
vim /etc/security/limits.conf
#在最后加入

• soft nofile 4096

• hard nofile 4096
  或者只加入

• • nofile 8192

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

roy soft nofile 8192
roy hard nofile 8192
注意”nofile”项有两个可能的限制措施。就是项下的hard和soft。 要使修改过得最大打开文件数生效，必须对这两种限制进行设定。 如果使用”-“字符设定, 则hard和soft设定会同时被设定。

3、检查程序问题
如果你对你的程序有一定的解的话，应该对程序打开文件数(链接数)上限有一定的估算，如果感觉数字异常，请使用第一步的lsof -p 进程id > openfiles.log命令，获得当前占用句柄的全部详情进行分析

对于linux来说，是有两个对打开文件数进行限制的地方，一个是ulimit中的open file，也就是ulimit -n，另一个则是inotify。Inotify是一种文件变化通知机制，Linux内核从2.6.13开始引入。它是一个内核用于通知用户空间程序文件系统变化的机制。开源社区提出用户态需要内核提供一些机制，以便用户态能够及时地得知内核或底层硬件设备发生了什么，从而能够更好地管理设备，给用户提供更好的服务，如 hotplug、udev 和 inotify 就是这种需求催生的。inotify 是一种文件系统的变化通知机制，如文件增加、删除等事件可以立刻让用户态得知，该机制是著名的桌面搜索引擎项目 beagle 引入的，并在 Gamin 等项目中被应用。

An “instance” is single file descriptor, returned by inotify_init(). A single inotify file descriptor can be used by one process or shared by multiple processes, so they are rationed per-user instead of per-process.

A “watch” is a single file, observed by inotify instance. Each watch is unique, so they are also rationed per-user.

If an application creates too many instances, it either starts too many processes (and does not share inotify file descriptors between processes), or it is just plain buggy — for example, it may leak open inotify descriptors (open and then forget about them without closing).

There is also a possibility, that application is just poorly written, and uses multiple descriptors where one could suffice (you almost never need more than 1 inotify descriptor).

Open file descriptors can by listed via procfs:

ls -al /proc//fd/
A bit of extra information about a descriptor can seen in /proc//fdinfo/.

查看服务器内核是否支持inotify

[root@czcb-poc-node1 etc]# ll /proc/sys/fs/inotify
-rw-r–r--. 1 root root 0 Mar 16 09:50 max_queued_events
-rw-r–r--. 1 root root 0 Mar 15 13:58 max_user_instances
-rw-r–r--. 1 root root 0 Mar 15 14:08 max_user_watches
查看系统默认参数值：

[root@czcb-poc-node1 etc]# sysctl -a | egrep “max_queued_events|max_user_watches|max_user_instances”
fs.epoll.max_user_watches = 26686791
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 8192
fs.inotify.max_user_watches = 8192
参数说明：

max_queued_events：

inotify队列最大长度，如果值太小，会出现"**Event Queue Overflow **"错误，导致监控文件不准确

max_user_watches：

操作（打开）的文件包含多少目录，可以用：find /home/tianwen -type d | wc -l 统计，必须保证max_user_watches值大于统计结果（这里/home/tianwen为同步文件目录）

max_user_instances：

每个用户创建inotify实例最大值

最后做了什么：实际上只是执行了一条命令，因为另外两个参数已经被修改了（umilit -n和user_watches），在各节点执行：

echo fs.inotify.max_user_instances=8192| tee -a /etc/sysctl.conf && sudo sysctl -p
因此最终的sysctl手工修改内容为：

fs.inotify.max_user_watches=65536
fs.inotify.max_user_instances=8192

ulimit -n 最大值为65535，这个值再增大也毫无意义，而且这个限定值针对的是程序，而非用户，因此不能完全解决打开文件数异常的原因。

目前该变更已经经过某之前数次检测到异常打开文件数的进行压力测试，测试时打开文件数约为之前异常时的1.5-2倍，持续3星期未再次发生异常，可以简单理解为已解决。