Linux中允许的最大最大打开文件数

10

Linux中可以配置的最大打开文件数量有（技术上或实践上）限制吗？如果将其配置为非常大的数量（例如1-100M），会产生一些不利影响吗？

我在这里考虑服务器的使用，而不是嵌入式系统。使用大量打开文件的程序当然会占用内存并且速度很慢，但是如果将限制配置为比必要的要大得多（例如，仅由配置消耗的内存），我会对不利影响感兴趣。

— 桑波
source

从理论上讲，你可以计算出有多少个文件描述符您的系统可以处理根据可用内存，并断言，每个FD占用内存的1K：serverfault.com/questions/330795/...

— 阿拉斯泰尔·麦科马克

10

我怀疑此限制的主要原因是为了避免过多的内存消耗（每个打开的文件描述符都使用内核内存）。它也可以防止错误的应用程序泄漏文件描述符并消耗系统资源。

但是，鉴于现代系统与10年前的系统相比有多少荒唐的RAM，我认为今天的默认值非常低。

在2011年，Linux上文件描述符的默认硬限制从1024增加到4096。

某些软件（例如MongoDB）使用的文件描述符比默认限制更多。MongoDB的人们建议将该限制提高到64,000。我已经将rlimit_nofile300,000用于某些应用程序。

只要将软限制保持为默认值（1024），增加硬限制可能就相当安全了。程序必须调用setrlimit()才能将其限制提高到软限制之上，并且仍然受到硬限制的限制。

另请参阅一些相关问题：

— AB
source

6

但是，这实际上并没有回答这个问题，该问题询问对硬限制的最高设置是否存在技术或实践上的限制。有，但是这个答案根本没有提及。

— JdeBP

我发现不可能将限制提高到超过一百万。我认为它可能在内核中是硬编码的，因为尽管更改了许多配置，但我不能超出这个范围。superuser.com/questions/1468436/...

— 帕维尔·科马罗夫

3

通常不会观察到这种影响，但是内核的IO模块将必须照顾所有这些打开的文件描述符，并且它们也可能会影响缓存效率。

这样的限制具有保护用户免受他们自己（或第三方）错误的好处。例如，如果您运行一个无限期派生的小程序或脚本，它将最终在ulimits 之一上阻塞，因此可以防止更严重（可能无法恢复）的计算机冻结。

除非有确切的理由增加这些限制中的任何一个，否则应避免使用该限制并改善睡眠。

— 朱莉·佩莱捷
source

2

从技术上讲，它限制为无符号长整数（C Lang）的最大值，即4,294,967,295

参考：fs.h文件

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

— 伦纳德·T
source

2

您对此有任何参考吗？

— 蒂姆（Tim）

同时这对32位的最大值签署整数，32位无符号整数，最大值为4,294,967,295。

— 萨姆波

你说得对，桑波。我的错。

— 伦纳德T

0

我认为您的担忧是可以理解的，但很可能Linux不会为配置的（但未使用的文件描述符）消耗大量内存：）

我不记得过去10年的职业生涯中出现过这样的问题。

问候。

— 蒂姆·康纳
source

0

安静一点，但这应该可以帮助其他人获得此问题的答案。在Linux中，打开文件的实际限制也可以使用进程可以打开的文件描述符的最大数目来计算。

我已经看到限制因系统而异。在getlimit手册页中，您可以看到RLIMIT_NOFILE-1内部指定了限制。

要检查RLIMIT_NOFILE值，可以使用以下语句获取元组

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

元组将结果返回为（Soflimit，hardlimit）。对我来说，在多个系统上运行的结果如下

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos

注意：9223372036854775807这个数字只是表示无穷大。在达到此目标之前，您将始终达到其他资源限制。如果您确实要修改系统上的硬限制，则必须修改内核参数。

— 安吉·库尔卡尼（Ankit Kulkarni）
source