在高并发的场景下，Nginx若配置不当，可能会报[crit]failed (24: Too many open files)的类似错误。这个错误的意思是指单个进程打开的文件句柄数已经达到了上限，无法再打开更多的文件句柄了。
我们先不管为什么一个进程会去打开那么多文件句柄，只说如何去解决这个问题。
按照搜索引擎上提供的常规解决方案，首先使用ulimit来查看系统当前支持最大打开文件句柄数。
其中配置项open files即为当前系统能打开的最大句柄数，系统默认一般为1024。
既然目前1024已经无法满足，那就对该配置项进行更改。
有两种方法进行更改：
1、使用ulimit配置指令
ulimit -SHn 1000000
ulimit 命令是分软限制和硬限制的，加-H就是硬限制，加-S就是软限制。默认显示的是软限制，如果运行ulimit 命令修改时没有加上-H或-S，就是两个参数一起改变。
软限制和硬限制的区别？
硬限制就是实际的限制，而软限制是警告限制，它只会给出警告。
但是这种配置方法有个问题，过一段时间该配置会被重置，推测可能是每次重新登录系统/退出系统后一段时间即会触发重置。
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
版权声明：本文为博主原创文章，转载请附上博文链接！
居然有这样的操作，赶紧试试。然后。。。。。。真的就解决了！
所以说网上文章一片抄，真正遇到问题并解决了问题的方案都被淹没在这些抄袭的低档次资料中了。
————————————————
版权声明：本文为CSDN博主「赖皮鹏」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/36/article/details/88351993