码迷,mamicode.com
首页 > 其他好文 > 详细

Too many open files错误与解决方法

时间:2017-08-02 13:18:28      阅读:110      评论:0      收藏:0      [点我收藏+]

标签: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之后问题解决。

 

  感悟:排查问题的思路清晰,循序渐进,最出彩的是排错过程中对各种细节的把握,服务的启动时间与配置文件的修改时间,这个细节让我很是受益,不亏是老运维出来的扎实功底。再敬 前辈。

Too many open files错误与解决方法

标签:conf   gre   环境变量   资源限制   报错信息   修改时间   shell   系统   目录   

原文地址:http://www.cnblogs.com/aaronax/p/7273163.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!