![Linux中允许的最大打开文件数](https://linux22.com/image/102122/Linux%E4%B8%AD%E5%85%81%E8%AE%B8%E7%9A%84%E6%9C%80%E5%A4%A7%E6%89%93%E5%BC%80%E6%96%87%E4%BB%B6%E6%95%B0.png)
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年的职业生涯中出现过这样的问题。
问候。