Too many open files错误与解决方法

致前辈：该问题的解决思路给了我很大的启发，文章做者Lis, Linux资深技术专家。

　　问题现象：这是一个基于Java的web应用系统，在后台添加数据时提示没法添加，因而登录服务器查看Tomcat 日志，发现以下异常信息，java.io.IOException:too many open files

　经过这个报错信息，基本判断是系统可使用的文件描述符不够了，因为Tomcat服务系统www用户启动的，因而以www 用户登录系统，经过ulimit -n 命令查看系统能够打开最大文件描述符的数量:

$ ulimit -n

65535

能够看到这台服务器设置的最大能够打开的文件描述符已是65535了，这么大的值应该够用了，可是为何提示这样的错误呢？

解决思路，这个案例涉及ulimit 命令的使用

在使用ulimit 时，有如下几种使用方法：

　　1.在用户环境变量中加入

若是用户使用的是bash，那么能够在用户目录的环境变量文件.bashrc或者.bash_profile中加入 ulimit -u 128 来限制用户最多可使用128个进程

　　2.在应用程序的启动脚本中加入

若是应用程序是Tomcat， 那么能够再Tomcat 的启动脚本startup.sh 中加入 ulimit -n 65535 来闲置用户最多可使用65535个文件描述符

　　3.直接在shell命令终端执行ulimit 命令

这种方法的资源限制仅仅在执行命令的终端生效，在退出或者和关闭终端后，设置失效，而且这个设置不影响其余shell 终端

解决问题：

　　在了解ulimit 知识后，接着上面的案例，既然ulimit 设置没有问题，那么必定是设置没有生效致使的，接下来检查下启动 Tomcat 的 www 用户环境变量是否添加 ulimit 限制，检查后发现，www 用户并没有ulimit限制。因而继续检查Tomcat 启动脚本startup.sh 文件是否添加了 ulimit限制，检查后发现也没有添加。最后考虑是否将限制加到了limits.conf文件中，因而检查limits.conf 文件，操做以下

#cat /etc/security/limits.conf | grep www

www soft nofile 65535

www hard nofile 65535

从输出可知，ulimit限制加在limits.conf文件中，既然限制已经添加了，配置 也没有什么错，为什么还会报错，通过思考，判断只有一种可能，那就是Tomcat 的启动时间早于ulimit 资源限制的添加时间，因而首先查看下Tomcat 启动时间，操做以下

#uptime

Up 283 days

#pgrep -f tomcat

4667

#ps -eo pid, lstart, etime | grep 4667

4667 Sat Jul 6 09;33:39 2013 77-05:26:02

从输出能够看出，这台服务器已经有283天没有重启了，而Tomcat 是在2013年7月6号9点启动的，启动了将近77天，接着看看limits.conf文件的修改时间，

#stat /etc/security/limits.conf

经过stat 命令清楚的看到，limits.conf文件最后的修改时间是2013年7月12日，晚于Tomcat启动时间，如此，重启Tomcat以后问题解决。

 

　　感悟：排查问题的思路清晰，按部就班，最出彩的是排错过程当中对各类细节的把握，服务的启动时间与配置文件的修改时间，这个细节让我非常受益，不亏是老运维出来的扎实功底。再敬 前辈。