☰

如何解释 nginx 的打开文件描述符的数量和最大文件描述符的数量？

tag-icon • tag-icon linux nginx ulimit sysctl file-descriptors
如何解释 nginx 的打开文件描述符的数量和最大文件描述符的数量？

我想获取 AWS Linux 实例上当前打开的文件描述符和打开文件描述符的上限。原因是确定是否增加 nginx 的限制以提供足够的文件描述符。

我得到以下输出：

$ulimit -a
open files                      (-n) 1024

$lsof | wc -l
397

$sudo lsof | wc -l
1870

$sysctl fs.file-nr
fs.file-nr = 1248   0   197688

从这个答案我读到这sysctl是内核中文件描述符的内存分配的硬性限制，但它ulimit似乎是一个可应用于特定域且仅针对每个具有会话范围的进程的限制。

我是否正确解释了上述价值观：

  1. ulimit显示nginx可以打开1024个文件每个进程.nginx 在该机器上运行 2 个工作进程，因此它有 2048 个可用的文件描述符。

  2. lsof显示登录用户（正在运行 nginx）的进程打开了 397 个文件。

  3. sudo lsof显示系统此刻共有 1870 个文件打开。

  4. sysctl显示系统范围内的最大文件描述符数量为 197688。这意味着，所有用户和该机器上运行的所有进程不能打开超过 197688 个文件。

  5. 当前打开的文件 1248 与 1870 之间的差异是由于它们的计数方式不同。file-nr忽略一些被 lsof 视为文件的目录。https://unix.stackexchange.com/q/176967/370277

调整 nginx 的限制：

  • Nginx amplify 目前显示nginx.workers.fds_count约为 300，罕见峰值可达 900。该值应显示两个工作进程的总和。这意味着即使考虑到峰值，nginx 也不会使用可用的 2048 个文件描述符的一半。我们这样还好吗？

  • nginx 配置nginx -T显示worker_connections 1024，这似乎是每个工作进程可以打开的连接数。每个工作进程每个连接需要 2 个文件描述符。因此，这里的限制是 1024 个 worker_connections * 每个连接 2 个文件描述符 * 2 个工作进程 = 4096 个文件描述符。但我们永远无法达到这个数字，因为两个 nginx 进程都只有 2048 个可用的文件描述符（根据上面的第 1 点）。对吗？

  • worker_rlimit_nofile没有在任何地方设置，而且我没有在文档。那么就没有限制吗？换句话说，如果worker_rlimit_nofile = worker_connections *2如所述这里，如果一个值决定了另一个值，为什么可以在 nginx 配置中设置这两个值？

相关内容