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

我在nginx上看到了常见的“文件描述符太多”的错误。经过大量search，解决scheme显然是增加可用于nginx的文件描述符的数量。但没有足够的信息让我觉得这样做有意义和安全的做法。以下是大多数论坛/电子邮件主题涵盖的要点：

操作系统有它自己的总文件描述符限制（在我的系统上， cat /proc/sys/fs/file-max outputs“100678”）
每个用户也可以有自己的限制（但在我的系统上，运行ulimit作为任何用户输出“无限” 更详细的底部看到更新 ）
有几个人说了些什么，这个人说：“指令worker_rlimit_nofile没有指定”多less“，这是操作系统的限制。指令worker_rlimit_nofile只是允许一个快速和肮脏的方式来扩大这个限制，如果它是不够的。所以我想这意味着，为nginx操作系统用户设置限制，而不是在configuration中“更好”？

我只需要input一个worker_rlimit_nofile的值，这个值比每个worker的连接数要大一些，但是我觉得我并不知道这里发生了什么。

为什么每个员工的限额要less于操作系统限制？
我怎么知道我现在的限制是什么？

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

worker_rlimit_nofile将设置工作进程的文件描述符的限制，与运行nginx的用户相反。如果在这个用户下运行的其他程序将无法正常处理文件描述符，那么你应该将这个限制设置得稍微小于用户的内容。

首先，什么是使用你的文件描述符？

每个活动连接到客户端
使用proxy_pass？这将打开一个处理这些请求的主机端口
使用proxy_pass到本地端口？那是另一个开放的sockets。（对于这个过程的所有者）
由nginx提供的静态文件

为什么每个员工的限制要less于操作系统限制？

这由操作系统控制，因为工作人员不是机器上唯一的进程。要为运行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的用户的ulimit 。

我怎么知道我现在的限制是什么？

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

必须检查来源是诚实的，但它是相当低的。

我用了worker_rlimit_nofile 15000; 并没有问题，你可以安全地增加它，但文件描述符用完的机会是微不足道的。