Too many open files 问题的解决办法

java.net.SocketException: Too many open files 问题的解决办法

linux 上tomcat 服务器抛出socket异常“文件打开太多”的问题
java.net.SocketException: Too many open files
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:70)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
原本以为是tomcat的配置或是应用本身的问题，"谷歌"一把后才发现，该问题的根本原因是由于系统文件资源的限制导致的。

具体可以参考http://www.bea.com.cn/support_pattern/Too_Many_Open_Files_Pattern.html
的说明。具体的解决方式可以参考一下：
1。ulimit -a 查看系统目前资源限制的设定。
   [root@test security]# umlimit -a
-bash: umlimit: command not found
[root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
[root@test security]#
通过以上命令，我们可以看到open files 的最大数为1024
那么我们可以通过一下命令修改该参数的最大值
2. ulimit -n 4096
[root@test security]# ulimit -n 4096
[root@test security]# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 4096
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited

这样我们就修改了系统在同一时间打开文件资源的最大数，基本解决以上问题。

以上部分是查找网络上的解决方法。设置了之后段时间内有作用。


后来仔细想来，问题还是要从根本上解决，于是把以前的代码由认真地看了一遍。终于找到了，罪魁祸首。

在读取文件时，有一些使用的BufferedReader 没有关闭。导致文件一直处于打开状态。造成资源的严重浪费。

修改之后的简单代码如下：


public void test(){
    BufferedReader reader =null;
    try{
        reader = 读取文件;
        String line = "";
        while( ( ine=reader.readLine())!=null){
           其他操作
        }

    } catch (IOException e){
        System.out.println(e);
    } finally{ 
         if(reader !=null){
                try {
                    reader.close();
                } catch (IOException e) {
                      e.printStackTrace();
                }
          }
    }

}


回答一、

[root@lxadmin nginx]# cat /proc/sys/fs/file-max
8192
文件系统最大可打开文件数
[root@lxadmin nginx]# ulimit -n
1024
程序限制只能打开1024个文件
使用[root@lxadmin nginx]# ulimit -n 8192调整一下
或者永久调整打开文件数 可在启动文件/etc/rc.d/rc.local末尾添加（在/etc/sysctl.conf末尾添加fs.file-max=xxx无效）

ulimit -n 8192

回答二、

Linux内核有时会报告“Too many open files”，起因是file-max默认值（8096）太小。要解决这个问题，可以root身份执行下列命令（或将它们加入/etc/rcS.d/*下的init脚本。）

# echo "65536"  > /proc/sys/fs/file-max  # 适用于2.2和2.4版内核
# echo "131072" > /proc/sys/fs/inode-max # 仅适用于2.2版内核

回答三、

办法是修改操作系统的打开文件数量限制，方法如下：

1. 按照最大打开文件数量的需求设置系统， 并且通过检查/proc/sys/fs/file-max文件来确认最大打开文件数已经被正确设置。
# cat /proc/sys/fs/file-max
如果设置值太小， 修改文件/etc/sysctl.conf的变量到合适的值。 这样会在每次重启之后生效。 如果设置值够大，跳过下步。
# echo 2048 > /proc/sys/fs/file-max
编辑文件/etc/sysctl.conf，插入下行。
fs.file-max = 8192

2. 在/etc/security/limits.conf文件中设置最大打开文件数， 下面是一行提示：
#
添加如下这行。
* - nofile 8192

这行设置了每个用户的默认打开文件数为2048。 注意"nofile"项有两个可能的限制措施。就是项下的hard和soft。 要使修改过得最大打开文件数生效，必须对这两种限制进行设定。 如果使用"-"字符设定, 则hard和soft设定会同时被设定。
硬限制表明soft限制中所能设定的最大值。 soft限制指的是当前系统生效的设置值。 hard限制值可以被普通用户降低。但是不能增加。 soft限制不能设置的比hard限制更高。 只有root用户才能够增加hard限制值。
当增加文件限制描述，可以简单的把当前值双倍。 例子如下， 如果你要提高默认值1024， 最好提高到2048， 如果还要继续增加， 就需要设置成4096。

另外一种情况是在创建索引的时候，也有两种可能，一种是 合并因子太小，导致创建文件数量超过操作系统限制，这时可以修改合并因子，也可以修改操作系统的打开文件数限制；另外一种是合并因子受虚拟机内存的限制，无法调整到更大，而 需要索引的doc 数量又非常的大，这个时候就只能通过修改操作系统的打开文件数限制来解决了。

在此基础上，我还修改了以下一个配置文件
vi /etc/sysctl.conf
添加：
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 30
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800
# Turn off tcp_window_scaling
net.ipv4.tcp_window_scaling = 0
# Turn off the tcp_sack
net.ipv4.tcp_sack = 0
#Turn off tcp_timestamps
net.ipv4.tcp_timestamps = 0
然后 service network restart,这些都和TCP sockets有关的优化。

另外需要在 /etc/rc.d/rc.local里添加已使得重启的时候生效。
echo "30">/proc/sys/net/ipv4/tcp_fin_timeout
echo "1800">/proc/sys/net/ipv4/tcp_keepalive_time
echo "0">/proc/sys/net/ipv4/tcp_window_scaling
echo "0">/proc/sys/net/ipv4/tcp_sack
echo "0">/proc/sys/net/ipv4/tcp_timestamps
因为不是所有的程序都在root下跑的，所有linux有对hard 与soft open files 的区分，普通用户受hard的限制，无论ulimit -n $数值调到多高，都跑不到 /etc/security/limits.conf里nofile的值.

这样的优化后 lsof -p $java_pid|wc -l可以跑到4千以上都不会抛出too many open files。