BEA-002616 问题解决

Too many open files问题分析

　　运行在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 <setting number> 命令。 

              对于文件描述符增加的比例，资料推荐是以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：

在Linux下面部署应用的时候，有时候会遇上Socket/File: Can’t open so many files的问题；这个值也会影响服务器的最大并发数，其实Linux是有文件句柄限制的，而且Linux默认不是很高，一般都是1024，生产服务器用其实很容易就达到这个数量。下面说的是，如何通过正解配置来改正这个系统默认值。因为这个问题是我配置Nginx+php5时遇到了，所以我将这篇归纳进nginx+apache篇。

查看方法

我们可以用ulimit -a来查看所有限制值

[root@centos5 ~]# ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

max nice                        (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 4096

max locked memory       (kbytes, -l) 32

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

max rt priority                 (-r) 0

stack size              (kbytes, -s) 10240

cpu time               (seconds, -t) unlimited

max user processes              (-u) 4096

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited||<

其中 "open files (-n) 1024 "是Linux操作系统对一个进程打开的文件句柄数量的限制(也包含打开的SOCKET数量，可影响MySQL的并发连接数目)。这个值可用ulimit命令来修改,但ulimit命令修改的数值只对当前登录用户的目前使用环境有效,系统重启或者用户退出后就会失效(在布署Nginx+FastCGI我就遇到这个问题，将ulimit -SHn
65535放到/etc/rc.d/rc.local也没起什么作用)

系统总限制是在这里，/proc/sys/fs/file-max。可以通过cat查看目前的值，修改/etc/sysctl.conf 中也可以控制。

另外还有一个，/proc/sys/fs/file-nr，可以看到整个系统目前使用的文件句柄数量。

查找文件句柄问题的时候，还有一个很实用的程序lsof。可以很方便看到某个进程开了那些句柄，也可以看到某个文件/目录被什么进程占用了。

修改方法

若要令修改ulimits的数值永久生效，则必须修改配置文档，可以给ulimit修改命令放入/etc/profile里面，这个方法实在是不方便，还有一个方法是修改/etc/sysctl.conf。我修改了，测试过，但对用户的ulimits -a 是不会改变的，只是/proc/sys/fs/file-max的值变了。

我认为正确的做法，应该是修改/etc/security/limits.conf

里面有很详细的注释，比如

* soft   nofile   32768

* hard nofile 65536

就可以将文件句柄限制统一改成软32768，硬65536。配置文件最前面的是指domain，设置为星号代表全局，另外你也可以针对不同的用户做出不同的限制。

注意：这个当中的硬限制是实际的限制，而软限制，是warnning限制，只会做出warning；其实ulimit命令本身就有分软硬设置，加-H就是硬，加-S就是软

默认显示的是软限制，如果运行ulimit命令修改的时候没有加上的话，就是两个参数一起改变。

生效

因为我平时工作最多的是部署web环境(Nginx+FastCGI外网生产环境和内网开发环境)，重新登陆即可(reboot其实也行)我分别用root和www用户登陆，用ulimit -a分别查看确认，做这之前最好是重启下ssh服务，service sshd restart。