java.io.IOException: Too many open files问题

在开发linux在线服务器的时候经常会遇会句柄泄露的问题。因为在linux系统设计里面遵循一切都是文件的原则，即磁盘文件、目录、网络套接字、磁盘、管道等，所有这些都是文件，在我们进行打开的时候会返回一个fd，即是文件句柄。如果频繁的打开文件，或者打开网络套接字而忘记释放就会有句柄泄露的现象。在linux系统中对进程可以调用的文件句柄数进行了限制，在默认情况下每个进程可以调用的最大句柄数是1024个，如果超过了这个限制，进程将无法获取新的句柄，而从导致不能打开新的文件或者网络套接字，对于线上服务器即会出现服务被拒绝的情况。

查看句柄：

在linux系统中可以通过ulimit–n查看每个进程限制的最大句柄数，通过ulimit –HSn 10240修改进程的最大句柄数。当句柄数目达到限制后，就回出现”too many files open”。

查看进程占用的句柄数有几种办法：

1） 通过cat/proc/pid/fd可以查看线程pid号打开的线程,cat   /proc/pid/fd |wc -l；

2） 通过lsof命令，需要root账号权限

查看当前系统的打开文件数：

# lsof | wc -l  

# watch "lsof | wc -l"

可以用lsof -p <pid of process>看打开的文件句柄数.查看某个进程的打开文件数

#lsof -p  1234|wc -l

 

查看Linux系统打开的文件句柄数：

# lsof -n | awk '{print $2}'| sort | uniq -c | sort -nr 

   3009 31312
     15 7364
     14 8002
     14 7777
     14 7382
     14 665
     14 6308
     ...
第一列：进程打开的文件句柄数
第二列：PID

 

应用日志报java.io.IOException: Too many open files

打开的文件过多，一般来说是由于应用程序对资源使用不当造成，比如没有及时关闭Socket或数据库连接等。但也可能应用确实需要打开比较多的文件句柄，而系统本身的设置限制了这一数量。

 

异常 1 
java.net.SocketException: Too many open files

    at java.net.PlainSocketImpl.accept(Compiled Code)
    at java.net.ServerSocket.implAccept(Compiled Code)
    at java.net.ServerSocket.accept(Compiled Code)
    at weblogic.t3.srvr.ListenThread.run(Compiled Code)

异常 2
java.io.IOException：打开的文件过多

    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.(UNIXProcess.java:54)
    at java.lang.UNIXProcess.forkAndExec(Native Method)
    at java.lang.UNIXProcess.(UNIXProcess.java:54)
    at java.lang.Runtime.execInternal(Native Method)
    at java.lang.Runtime.exec(Runtime.java:551)
    at java.lang.Runtime.exec(Runtime.java:477)
    at java.lang.Runtime.exec(Runtime.java:443)

...

第一个异常在错误影响到基础 TCP 协议时抛出，而第二个异常则在错误影响到 I/O 操作时抛出，这个是由于交换分区不足造成的。

文件打开数过多最坏的情况可以使系统崩溃，到时候只能是重起服务器了。 

 

原因:  

　1、大多数情况是程序没有正常关闭一些资源引起的，所以出现这种情况，请检查io读写，socket通讯等是否正常关闭。

　　操作系统的中打开文件的最大句柄数受限所致，常常发生在很多个并发用户访问服务器的时候。因为为了执行每个用户的应用服务器都要加载很多文件(new一个socket就需要一个文件句柄),这就会导致打开文件的句柄的缺乏。 

       主要方向：在源码项目中查找所有引用了InputStream或者其他流的地方，查看其是否在使用完后，正常close掉，此处建议将流的close放到finally块中，这样异常时也会去close流。

       次要方向：session或者其他有用到socket的代码处，仔细查询看是否有没有释放资源的地方

 
   2、 如果检查程序没有问题，那就有可能是linux默认的open files值太小，不能满足当前程序默认值的要求，比如数据库连接池的个数，tomcat请求连接的个数等。。。 

         限制：有时是linux系统的参数的限制，需要修改内核参数。有时是中间件（weblogic、nginx）中启动文件参数限制，尤其是默认1024，在修改linux后若中间件有涉及也要同步修改。

      

 

解决:

尽量把类打成jar包,因为一个jar包只消耗一个文件句柄,如果不打包,一个类就消耗一个文件句柄.
java的垃圾回收不能关闭网络连接打开的文件句柄,如果没有执行close()(例如:java.net.Socket.close())则文件句柄将一直存在,而不能被关闭.你也可以考虑设置socket的最大打开数来控制这个问题.
对操作系统做相关的设置,增加最大文件句柄数量。


Linux
在 Linux内核2.4.x中需要修改源代码，然后重新编译内核才生效。编辑Linux内核源代码中的 include/linux/fs.h文件，将 NR_FILE 由8192改为65536，将NR_RESERVED_FILES 由10 改为 128。编辑fs/inode.c 文件将MAX_INODE 由16384改为262144。或者编辑 /etc/sysctl.conf  文件增加两行 fs.file-max = 65536 和 fs.inode-max = 262144 。一般情况下，系统最大打开文件数比较合理的设置为每4M物理内存256，比如256M.

 

在linux下的fd是有限制的，一个是系统的限制，一个是用户进程限制。

 

服务器端修改：

查看系统允许打开的最大文件数

#cat /proc/sys/fs/file-max

sysctl fs.file-max=655360可以调整内核的阈值，前提得有root权限。可参考/etc/sysctl.conf，用man sysctl.conf命令sysctl -a可以显示所有的能够调整参数。

 

查看每个用户允许打开的最大文件数

ulimit -a

发现系统默认的是open files (-n) 1024，问题就出现在这里。

在系统文件/etc/security/limits.conf中修改这个数量限制，

在文件中加入内容：

* soft nofile 65536
* hard nofile 65536

 

另外方法：
1.使用ps -ef |grep java   (java代表你程序，查看你程序进程) 查看你的进程ID，记录ID号，假设进程ID为12
2.使用：lsof -p 12 | wc -l    查看当前进程id为12的 文件操作状况
    执行该命令出现文件使用情况为 1052
3.使用命令：ulimit -a   查看每个用户允许打开的最大文件数
    发现系统默认的是open files (-n) 1024，问题就出现在这里。
4.然后执行：ulimit -n 4096
     将open files (-n) 1024 设置成open files (-n) 4096

这样就增大了用户允许打开的最大文件数

 

同时查看ulimit实际是否生效，如果设置了但并未生效也不行。

运维实战案例之“Too many open files”错误与解决方法 

此文中就介绍了设置了参数，但并未生效引起的。

 

 

socket未关闭现象

1. 首先用lsof -p PID 查看一下打开文件的列表如果出现下图状况基本就两种可能，stream未关闭或者socket未关闭，出现can't identify protocol字样

2. 用netstat -anp | grep PID查看端口占用情况，若出现下图情况，证明Socket未关闭

原因：

　　是因为Socket协议本身，若正确关闭一个Socket需要往返消息4次，若中途有未接到的消息就会停留在某个状态下，比如当前的CLOSE_WAIT。

        如果close_wait状态过多，可能是socket未关闭引起。

解决办法：

　　客户端：主动关闭任何一个socket，尽量在finally中加入socket.close()语句。

　　服务器：设置读取超时时间如：socket.setSoTimeout(3000);其次在用完之后主动关闭，做法同客户端方式。同时在任何的异常加入socket.shutdownInput();socket.shutdownOutput();

 

问题定位

问题定位步骤：
1、   用root帐户 遍历 /proc/进程ID/fd目录，若该目录下文件数较大（如果大于10一般就属于socket泄漏），根据该进程ID，可以确认该进程ID所对应的名称。
2、   重启程序恢复服务，以便后续查找问题。
3、   strace 该程序并记录strace信息。strace –p 进程ID >>/tmp/stracelog.log 2>&1
4、   查看 /proc/进程ID/fd 下的文件数目是否有增加，如果发现有增加，记录上一个socket编号，停止strace
5、   确认问题代码的位置。打开/tmp/stracelog.log，从尾部向上查找close(socket编号)所在行，可以确认在该次close后再次创建的socket没有关闭，根据socket连接的server ip可以确认问题代码的位置。


另一种方法:判断是否有socket泄漏:
lsof | grep "can't identify protocol"
如果存在很多，则代表socket泄漏，同时会显示哪个进程使用的sock未关闭。

 

文件句柄泄露定位方法：

1、使用lsof命令查出有哪些文件或者socket被打开。

2、根据文件名找到相应的模块，检查相关的代码.如果是socket，则根据端口号找到相应的模块，最后检查相关的代码。

 

 

 

 

mina高并发短连接导致java.io.IOException: Too many open files解决方案

  1.         //设置超时   
  2.         connector.setConnectTimeoutMillis(defaultConnectTimeOut);  
  3.         ConnectFuture connectFuture = connector.connect(address);  
  4.         connectFuture.awaitUninterruptibly();   //同步，等待，直到连接完成   
  5.         if  (connectFuture.isDone()) {  
  6.             if  (!connectFuture.isConnected()) {  //若在指定时间内没连接成功，则抛出异常   
  7.                 logger.info("fail to connect "  + logInfo);  
  8.   
  9.                 throw   new  Exception();  
  10.             }  
  11.         }  

 

         经过分析，导致主机文件句柄泄露的原因为，客户端发起服务端连接时，会请求系统分配相关的文件句柄，在原代码中，仅仅判断是否连接成功，而未对连接失败进 行资源释放，从而造成文件句柄泄露。当总的文件句柄数超过系统设置值（ulimit -n 查看同一个进程允许的最大文件句柄数），则抛出异常“java.io.IOException: Too many open files",导致无法创建新的连接，服务器挂掉。

      更改后的代码如下：

 

Java代码  收藏代码
  1. final  NioSocketConnector connector =  new  NioSocketConnector();  
  2.         final  String[] result =  new  String[ 1 ];  
  3.         connector.getFilterChain().addLast("codec" ,  
  4.                 new  ProtocolCodecFilter( new  ObjectSerializationCodecFactory()));  
  5.         connector.setHandler(handler);  
  6.   
  7.         //设置超时   
  8.         connector.setConnectTimeoutMillis(defaultConnectTimeOut);  
  9.         ConnectFuture connectFuture = connector.connect(address);  
  10.         connectFuture.awaitUninterruptibly();   //同步，等待，直到连接完成   
  11.         if  (connectFuture.isDone()) {  
  12.             if  (!connectFuture.isConnected()) {  //若在指定时间内没连接成功，则抛出异常   
  13.                 logger.info("fail to connect "  + logInfo);  
  14.                 connector.dispose();    //不关闭的话会运行一段时间后抛出，too many open files异常，导致无法连接   
  15.   
  16.                 throw   new  Exception();  
  17.             }  
  18.         }  

 

 

from http://www.jianshu.com/p/2e6748c4c0b7

 

原因一：Linux 的open files 数不够

[root@chances125 ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 78454
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
lsof -n |awk '{print $2}'|sort|uniq -c |sort -nr|more
#查一下当前已有的连接数，再来判断open files 为1024 是不是小
lsof -p $java_pid | wc -l
#加大打开的文件数
ulimit -n 2048
#用户级别的修改

#系统级设置对所有用户有效。
#可通过两种方式查看系统最大文件限制                 
cat /proc/sys/fs/file-max          
#修改配置/etc/sysctl.conf文件
fs.file-max=2048
#通知系统启用这项配置 
sysctl -p

 

原因二：TCP 参数配置不对

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  
TIME_WAIT 7091
CLOSE_WAIT 2
ESTABLISHED 716
LISTEN 10

常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭
服务器保持了大量TIME_WAIT状态

#参数优化
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout = 30
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒，原因是：当前都是图片，不需要建立长链接
net.ipv4.tcp_keepalive_time = 300
#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
net.ipv4.tcp_syncookies = 1
#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭，当前TIME-WAIT 过多，所以开启快速回收
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000 65000

配置生效后，观察结果，TIME_WAIT 明显减少。

TIME_WAIT 2492
CLOSE_WAIT 10
ESTABLISHED 730
LISTEN 10

原因三：Tomcat 配置不对

connectionTimeout - 网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
当前配置connectionTimeout=0

根据公式：服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量

待测试验证

 

原因四：程序打开了许多文件，但未关闭连接

之前一直在找程序哪里打开了文件却未关闭连接，未果。
才想到连接打开后，多久可以关闭。

lsof -i :80
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    3011 root  837u  IPv6            3513129        0t0     TCP sc-epg-app15:8085->10.223.52.16:38494 (ESTABLISHED)
java    3011 root  838u  IPv6              31731        0t0     TCP sc-epg-app15:8085->10.230.160.147:38903 (ESTABLISHED)
java    3011 root  839u  IPv6            3667505        0t0     TCP sc-epg-app15:8085->10.251.207.71:35411 (ESTABLISHED)
#NODE　对应的是ＴＣＰ
#PID ３０１１，当前服务器上只有一个应用。

待解决的问题是：
１）如何定位到程序代码什么地方打开了文件？
２）打开的这些文件是不是都是必要的？
３）can't identify protocol的原因



 


参考资料：


1、http://www.2cto.com/kf/201212/175863.html


2、http://marsvaadin.iteye.com/blog/1698924


3、MINA2 错误解决方法-- Linux下tomcat报错“java.net.SocketException: Too many open files”


4、tcp socket文件句柄泄漏


 






            

            
posted @ 
2014-05-18 20:57 
milkty 
阅读(12317) 
评论(0) 
编辑 
收藏 
举报