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

Question

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

• 操作系统有自己的总文件描述符限制（在我的系统上，cat /proc/sys/fs/file-max输出“100678”）
• 每个用户也可以有自己的限制（但在我的系统上，ulimit在任何用户输出“无限”时运行，请参阅底部更新的更多详细信息）
• 一些人说了一些与此人所说的类似的话：'指令 worker_rlimit_nofile 没有指定“多少”，而是操作系统限制。如果不够，指令 worker_rlimit_nofile 只允许一种快速而肮脏的方式来扩大这个限制。所以我想这意味着为 nginx OS 用户设置限制而不是在配置中设置限制“更好”？

我可以将 worker_rlimit_nofile 值放入大于每个工作器连接数的值，并称其为一天，但我觉得我真的不知道这里发生了什么。

• 为什么每个工人的限制会小于操作系统限制？
• 我如何知道我现在的极限是多少？

更新：对根和一个普通用户，输出的ulimit“无限制”，但ulimit -Hn和ulimit -Sn两个输出1024

Answer 1

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

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

1. 每个与客户端的活动连接
2. 使用proxy_pass？这将打开一个到 host:port 处理这些请求的套接字
3. 使用 proxy_pass 到本地端口？那是另一个打开的套接字。（对于该过程的所有者）
4. 由 nginx 服务的静态文件

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

这是由操作系统控制的，因为 worker 不是机器上运行的唯一进程。要为运行 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 -a 将显示与您运行它的用户相关的所有限制。