标签：conf gre 环境变量 资源限制 报错信息 修改时间 shell 系统 目录
致前辈：该问题的解决思路给了我很大的启发，文章摘抄自 马哥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之后问题解决。
感悟：排查问题的思路清晰，循序渐进，最出彩的是排错过程中对各种细节的把握，服务的启动时间与配置文件的修改时间，这个细节让我很是受益，不亏是老运维出来的扎实功底。再敬 前辈。
标签：conf gre 环境变量 资源限制 报错信息 修改时间 shell 系统 目录
原文地址：http://www.cnblogs.com/aaronax/p/7273163.html
