解决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日志，大量的如下信息：
<!--[if !supportLineBreakNewLine]-->

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)

  <!--[endif]-->事件的主题：linux系统出现Too many open files 错误，这是因为文件描述符大小不够，或者有不正常的网络连接(Socket也是一种特殊的文件)、文件IO没有关闭并释放出文件描述符（文件句柄，File Operator）。

使用如下命令查看系统对允许打开最大文件描述符的配置：
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。