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

我在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

worker_rlimit_nofile将为工作进程设置文件描述符的限制，这与运行nginx的用户相反。如果在该用户下运行的其他程序无法正常处理文件描述符用尽的情况，则应将此限制设置得比该用户的设置小一些。

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

1. 到客户端的每个活动连接
2. 使用proxy_pass？这将打开主机的套接字：处理这些请求的端口
3. 使用proxy_pass到本地端口？多数民众赞成在另一个开放的插座。（对于该过程的所有者）
4. 由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。

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

ulimit -a 将显示与您作为其运行用户的所有限制。

坦白地说，必须检查源，但是它的数量很少。

我曾经使用过worker_rlimit_nofile 15000;，但没有问题，您可以放心地增加它，但是，用完文件描述符的机会很小。