☰

文件描述符数量限制

tag-icon • tag-icon linux file-descriptors ulimit
文件描述符数量限制

我正在尝试安装389-ds，它给了我这个警告：

WARNING: There are only 1024 file descriptors (hard limit) available, which limit the number of simultaneous connections.

我了解文件描述符，但不了解软限制和硬限制。

当我奔跑时cat /proc/sys/fs/file-max，我会回来590432。这应该意味着我最多可以打开 590432 个文件（即最多有 590432 个文件描述符。

但是当我运行时ulimit，它给了我不同的结果：

$ ulimit
unlimited

$ ulimit -Hn    # Hard limit
4096

$ ulimit -Sn    # Soft limit
1024

但是硬/软限制来自哪里ulimit，它们与存储的数字有何关系/proc/sys/fs/file-max？

答案1

根据内核文档,/proc/sys/fs/file-max是文件的最大总数、全局数量把手内核将在阻塞之前进行分配。这是内核的限制，而不是当前用户的限制。那么你能打开 590432，前提是您独自在空闲系统上（单用户模式，没有守护程序运行）。文件句柄（struct file内核中）与文件描述符不同：多个文件描述符可以指向同一个文件句柄，文件句柄也可以存在没有内部关联的描述符。没有设置系统范围的文件描述符限制；这只能针对每个进程强制执行。

请注意，该文档已过时：该文件已经存在/proc/sys/fs/file-max很长时间了。感谢 Martin Jambon 指出了这一点。

软限制和硬限制之间的区别在 SE 上得到了解答。您可以作为普通用户提高或降低软限制，前提是您不超过硬限制。您还可以降低硬限制（但您不能在该过程中再次提高它）。作为超级用户，您可以提高和降低硬限制和软限制。双重限制方案用于强制执行系统策略，但也允许普通用户为自己设置临时限制并在以后更改它们。

请注意，如果您尝试将硬限制降低到软限制以下（并且您不是超级用户），您将返回EINVAL（无效参数）。

因此，在您的特定情况下，ulimit（与 相同ulimit -Sf）表示您对shell 及其子进程写入的文件大小。 （在大多数情况下这可能是个好主意）

您的其他调用ulimit -Hn报告限制-n（打开文件描述符的最大数量），不是限制-f，这就是为什么软限制似乎高于硬限制的原因。如果您输入，ulimit -Hf您还将获得unlimited.

答案2

“select”系统调用是unix众多可怕的脑死亡设计决策之一，它使得甚至windows95相比之下仍然看起来那么好。

它应该在 20 年前就被禁止，然后我们现在就可以毫无问题地限制文件处理程序了。

您可以使用内核配置和 ulimit 轻松增加文件描述符的数量，但请记住，如果任何库使用“select”系统调用，您的程序将变得不稳定并失败（除非作者知道并测试传递的文件描述符数量是否更大）比 FD_SET_MAX 并且在这种情况下切换到使用 poll 或 epoll 在这种情况下，不清楚为什么它从一开始就没有考虑到这一点）。

select 只能处理从 0 到 1023 的文件描述符（或者 FD_SET 硬编码常量中设置的其他内容），如果您给一个更高的值提供文件描述符，它会随机地在您的内存中插入，并且 select 永远不会重复该描述符工作。不幸的是，许多库仍然使用 select，并且您会在所有示例代码和教程中看到它的使用。

太可怕了，这就是为什么这个评论是咆哮和答案的原因。无法不生气地回答。

相关内容