too many open files这种错误应该怎么解决

too many open files这种错误应该怎么解决

Tomcat Too Many Open Files ;Too many open files tomcat 6.0报“too many open files Too many open files 问题的解决 linux 故障解决，tomcat 故障处理，too many open files 故障处理

发表于 2011 年 01 月 06 日 由 admin

Tomcat Too Many Open Files ;Too many open files tomcat 6.0报“too many open files Too many open files 问题的解决

linux 故障解决，tomcat 故障处理，too many open files 故障处理这个问题是第一次在Linux环境下碰到，把解决的方法记录下来。

服务器配置：两个双核CPU 2.0G，4G内存

操作系统：CentOS，内核2.6.18

应用1、搜索服务器，负责全站的搜索和提供内容相关性接口

应用服务器：Tomcat6.0.16+Apache2.2.8，其中两个Tomcat实例，一个对外提供服务，一个对内管理索引(创建、删除、检索等)

Web方案：Solr1.3(With Solr Client For Java)、Java Servlet(Web Service 接口)

应用2、类似于百度知道的一个应用

应用服务器：与搜索服务器共享Apache2.2.8

Web方案：Php+Mysql

问题症状：搜索服务停止，应用2响应超时，牵连全站的搜索接口调用内容的输出，查看Catalina日志，大量的如下信息：

Java代码

org.apache.jk.common.ChannelSocket acceptConnections

WARNING: Exception executing accept

java.net.SocketException: Too many open files

at java.net.PlainSocketImpl.socketAccept(Native Method)

at java.net.PlainSocketImpl.accept(Unknown Source)

at java.net.ServerSocket.implAccept(Unknown Source)

at java.net.ServerSocket.accept(Unknown Source)

at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:295)

at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:641)

at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

at java.lang.Thread.run(Unknown Source)

org.apache.jk.common.ChannelSocket acceptConnections

WARNING: Exception executing accept

java.net.SocketException: Too many open files

at java.net.PlainSocketImpl.socketAccept(Native Method)

at java.net.PlainSocketImpl.accept(Unknown Source)

at java.net.ServerSocket.implAccept(Unknown Source)

at java.net.ServerSocket.accept(Unknown Source)

at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:295)

at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:641)

at org.apache.jk.common.SocketAcceptor.runIt(ChannelSocket.java:852)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

at java.lang.Thread.run(Unknown Source)

使用如下命令查看系统对允许打开最大文件描述符的配置：

ulimit -u 查看open files设置

ulimit -a 查看所有设置

ulimit -u 65535(新的open files 值)修改设置

ulimit -n 65536 设置用户可以同时打开的最大文件数（max open files）

如果本参数设置过小，对于并发访问量大的网站，可能会出现too many open files的错误

使用lsof -p pid [httpd进程的 pid、java的pid]来查看系统中apache进程和java运行时进程当前打开的文件资源，发现两者之和已经接近1024，大于了默认的设置。

修改配置：

修改/etc/security/limits.conf，在文件末加上

* soft nofile 65536

* hard nofile 65536

系统级文件描述符极限还可以通过将以下三行添加到 /etc/rc.d/rc.local 启动脚本中来设置：

# Increase system-wide file descriptor limit.

echo 65536 > /proc/sys/fs/file-max

echo 65536 > /proc/sys/fs/inode-max

思考：虽 然调整该参数解决了当前的问题，但并不是最好的方法，出现该错误说明该服务器承载了一定的并发连接，尤其是搜索服务，其中一个实例对外提供搜索，另一个实 例创建索引，两个实例之间也使用socket进行通信(httpclient for java)，创建索引的时候会占用大量的文件描述符，如果描述符没有及时释放(不能完全依赖垃圾回收机制，要及时的close)；全站的所有与搜索有关的 接口调用都会向其发出请求，而应用2也对外服务不少的请求，较好的办法是将搜索服务从该服务器中分离出来，这样可以分别对两者进行优化(包括调整 Linux系统参数，比如：/etc/sysctl.conf中对net.ipv4的优化)，出了问题也容易debug