理解linux和nginx的最大文件描述符,以及worker_rlimit_nofile的最佳值

我在nginx上遇到了看似常见的“太多文件描述符”错误.经过大量搜索后,解决方案显然是增加了nginx可用的文件描述符数量.但是没有足够的信息让我觉得以一种有意义和安全的方式做到这一点很舒服.以下是大多数论坛/电子邮件主题涵盖的要点：

>操作系统有自己的总文件描述符限制(在我的系统上,cat / proc / sys / fs / file-max输出“100678”)
>每个用户也可以拥有自己的限制(但在我的系统上,运行ulimit,因为任何用户输出“无限制”,请参阅底部更新,详细信息)
>一些人说了些什么,就像this person所说：’指令worker_rlimit_nofile没有指明
“多少”,这是操作系统的限制.指示
worker_rlimit_nofile只允许快速而肮脏的放大方式
这个限制,如果还不够的话.所以我想这意味着为nginx OS用户设置限制而不是在配置中“更好”？

我可以输入一个worker_rlimit_nofile值大于每个worker的连接数并且每天调用它,但我觉得我真的不知道这里发生了什么.

>为什么每个工人的限制会低于操作系统限制？
>我如何找出我现在的限制？

更新：对于root用户和普通用户,ulimit输出“unlimited”,但是ulimit -Hn和ulimit -Sn都输出1024

解决方法

worker_rlimit_nofile将为工作进程设置文件描述符的限制,与运行nginx的用户相反.如果在此用户下运行的其他程序无法正常处理文件描述符的用完,那么您应该将此限制设置为略低于用户的限制.

首先,什么是使用您的文件描述符？

>与客户端的每个活动连接
>使用proxy_pass？这将打开一个到主机的套接字：处理这些请求的端口
>使用proxy_pass到本地端口？那是另一个打开的插座. (对于该过程的所有者)
> nginx提供的静态文件

为什么每个工人的限制低于操作系统限制？

这由操作系统控制,因为工作人员不是机器上运行的唯一进程.要为运行nginx的用户更改它,请参阅下文.如果您的工作人员用尽了所有进程可用的所有文件描述符,那么这将是非常糟糕的,不要设置限制以便可行.

#/etc/sysctl.conf
#This sets the value you see when running cat  /proc/sys/fs/file-max
fs.file-max = 65536"


#/etc/security/limits.conf
#this sets the defaults for all users
* soft nofile 4096
* hard nofile 4096

#This overrides the default for user `usernamehere`
usernamehere soft nofile 10240
usernamehere hard nofile 10240

在那些安全限制更改后,我相信我仍然必须使用ulimit增加用户的softlimit.

我如何找出我现在的限制？

ulimit -a将显示与您运行它的用户相关的所有限制.