nginx: Too many open files解决

在高并发的场景下，Nginx若配置不当，可能会报[crit]failed (24: Too many open files)的类似错误。这个错误的意思是指单个进程打开的文件句柄数已经达到了上限，无法再打开更多的文件句柄了。

我们先不管为什么一个进程会去打开那么多文件句柄，只说如何去解决这个问题。

按照搜索引擎上提供的常规解决方案，首先使用ulimit来查看系统当前支持最大打开文件句柄数。

使用： ulimit -a 查看最大句柄

其中配置项open files即为当前系统能打开的最大句柄数，系统默认一般为1024。

既然目前1024已经无法满足，那就对该配置项进行更改。

有两种方法进行更改：

1、使用ulimit配置指令

ulimit -SHn 1000000

 ulimit 命令是分软限制和硬限制的，加-H就是硬限制，加-S就是软限制。默认显示的是软限制，如果运行ulimit 命令修改时没有加上-H或-S，就是两个参数一起改变。

使用 ulimit-SHn 1000000 可以把打开文件数设置足够大， 同时修改nginx.conf ， 添加 worker_rlimit_nofile 655350； （与error_log同级别）

软限制和硬限制的区别？
硬限制就是实际的限制，而软限制是警告限制，它只会给出警告。

但是这种配置方法有个问题，过一段时间该配置会被重置，推测可能是每次重新登录系统/退出系统后一段时间即会触发重置。

2、通过配置文件永久变更

vi /etc/security/limits.conf

*******************************************
#max user processes
* soft nproc 65535  
* hard nproc 65535
#open files
* soft nofile 1000000
* hard nofile 1000000

 在配置文件的末尾加上上述配置内容。修改后保存，注销当前用户（exit），重新登录后，参数生效。

以上修改是对一个进程打开的文件句柄数量限制，而系统还有个总限制。

单个进程打开的文件句柄数，不能超过这个系统总限制。当然这个总限制是可以更改的，根据需要进行适当调整。

做完以上操作，按理已经可以解决Too many open files的异常了，毕竟大部分搜索出来的解决方案到此为止。但是，笔者配置完成后，第二天观察仍然如故。。。

检查参数配置情况，都按要求进行了配置，看起来也是已经生效，但是奈何Nginx还是报异常。悲乎哉！

于是开始了漫长的求索之旅。

首先想到的是监控系统当前总的文件句柄数，根据采集的句柄数样本来配置最大打开文件句柄参数。使用如下指令：

/usr/sbin/lsof|awk '{print $2}'|wc -l >> /root/listenfilemax.log

 并开启了定时任务，每隔1分钟执行一次（这里强调下，在定时任务里面执行指令，最好带上绝对路径）。结果却让人非常的无奈，正常情况下采集很成功，但在报异常的时间点，居然无法采集到系统当前消耗的总句柄数。。。

某次搜索Nginx配置项说明时，在一篇文章中提到，可使用worker_rlimit_nofile参数控制Nginx的文件句柄打开参数。文章中提到：

worker_rlimit_nofile 更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。
---------------------
作者：席飞剑
来源：CSDN
原文：https://blog.csdn.net/xifeijian/article/details/20956605
版权声明：本文为博主原创文章，转载请附上博文链接！

居然有这样的操作，赶紧试试。然后。。。。。。真的就解决了！