1、问题阐述:
too many open files:顾名思义即打开过多文件数。
不过这里的files不单是文件的意思,也包括打开的通讯链接(比如socket),正在监听的端口等等,所以有时候也可以叫做句柄(handle),这个错误通常也可以叫做句柄数超出系统限制。
2、产生的原因:
经常在使用linux的时候出现,大多数情况是由于程序没有正常关闭一些资源引起的,所以出现这种情况,请检查io读写,socket通讯等是否正常关闭。
3、经典案例:
很多项目上线不久运行了一段时间后,服务突然宕了,经检查日志,出现了too many open files 错误。
![](https://images2018.cnblogs.com/blog/1024536/201803/1024536-20180321234638641-1149429179.png)
4、解决方案:
前奏:其实Linux是有文件句柄限制的,而且默认不是很高,一般都是1024,作为一台生产服务器,其实很容易就达到 这个数量,因此我们需要把这个值改大一些。我们可以用ulimit -n 来查看当前用户句柄数限制。那么这个1024是系统的限制,还是用户的限制呢。其实,这个是用户限制来的,完整的说法,应该是当前用户准备要运行的程序的限制。
1、这个限制是针对单个程序的限制
2、这个限制不会改变之前已经运行了的程序的限制
3、对这个值的修改,退出了当前的shell就会消失
因此出现这种问题有两种解决方式:
第一:增大文件句柄数。这种方式能及时解决问题,但是不能够彻底的解决问题,可以为彻底解决问题提供一定的时间保证。那么如何增大文件句柄数数呢?
如修改文件句柄数为65535,ulimit -n 65535.此时系统的文件句柄数为65535.
2)将ulimit 值添加到/etc/profile文件中(适用于有root权限登录的系统)
为了每次系统重新启动时,都可以获取更大的ulimit值,将ulimit 加入到/etc/profile 文件底部。
echo ulimit -n 65535 >>/etc/profile
source /etc/profile #加载修改后的profile
ulimit -n #显示65535,修改完毕!
到此为止,你以为大功告成了么,其实不然,突然发现自己再次登录进来的时候,ulimit的值还是1024,这是为什么呢? 用户登录的时候执行sh脚本的顺序:
/etc/profile.d/file
/etc/profile
/etc/bashrc
/mingjie/.bashrc
/mingjie/.bash_profile
由于ulimit -n的脚本命令加载在第二部分,用户登录时由于权限原因在第二步还不能完成ulimit的修改,所以ulimit的值还是系统默认的1024。所以想彻底改变这种问题,就必须做如下操作:修改/etc/security/limits.conf
里面有很详细的注释,比如
* soft nofile 2048
* hard nofile 32768
就可以将文件句柄限制统一改成软2048,硬32768
那么什么是软限制,什么是硬限制
硬限制是实际的限制,而软限制,是warnning限制,只会做出warning
这样就实实际际的增大了文件句柄数。
第二:分析句柄数,查找原因,这是解决问题最根本的办法。那么如何分析那,就需要用到lsof这个命令了(关于这个命令大家可以在网上学习学习)。
(1)统计各进程打开句柄数:lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr
(2)统计各用户打开句柄数:lsof -n|awk '{print $3}'|sort|uniq -c|sort -nr
(3)统计各命令打开句柄数:lsof -n|awk '{print $1}'|sort|uniq -c|sort -nr
就掌商通来说,通过命令分析发现是一个叫xmpp的东西打开的连接数居多,占到了单个进程总打开连接数的百分之八十以上,再仔细分析,xmpp是消息推送产生的连接,那么到这里问题比较明确了,接下来就是要分析为什么消息推送会打开如此多的文件句柄,且一直连着也不断开。这样问题就定位了。另外还有一些进程打开文件句柄数也比较多,这时你可以对比其他服务器,看是否其他服务器也是如此,以保证全面的解决问题。