☰

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

tag-icon • tag-icon linux files limit open-files
Linux中允许的最大打开文件数

Linux 中可以配置的最大打开文件数是否有（技术或实际）限制？如果配置很大（比如1-100M）会有什么不良影响吗？

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

答案1

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

但考虑到现代系统的 RAM 与 10 年前的系统相比是多么荒谬，我认为今天的默认值相当低。

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

某些软件（例如 MongoDB）使用的文件描述符比默认限制多得多。 MongoDB 人建议将此限制提高到 64,000。rlimit_nofile对于某些应用程序，我使用了300,000 个。

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

另请参阅一些相关问题：

答案2

从技术上讲，它仅限于 unsigned long (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 */
};

答案3

这种影响通常是无法观察到的，但内核的 IO 模块必须处理所有这些打开的文件描述符，并且它们也可能对缓存效率产生影响。

此类限制的优点是可以保护用户免受自己（或第三方）错误的影响。例如，如果您运行一个无限期分叉的小程序或脚本，它最终会在其中一个上阻塞ulimit，从而防止更严重的（可能无法恢复的）计算机冻结。

除非您有明确的理由增加这些限制，否则您应该避免这样做并睡得更好。

答案4

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

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

问候。

相关内容