☰

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

tag-icon • tag-icon linux nginx ulimit
了解 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值然后就完事了，但是我觉得我真的不知道这里发生了什么。

  • 为什么每个工人的限制会低于操作系统的限制？
  • 我如何才能知道我的当前限额是多少？

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

答案1

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将显示与您以之运行的用户相关的所有限制。

答案2

老实说必须检查来源，但是这个数字相当低。

我使用过worker_rlimit_nofile 15000;并且没有遇到任何问题，你可以安全地增加它，但是，耗尽文件描述符的可能性很小。

相关内容