增加/etc/security/limits.conf中的“nofile”限制会产生什么影响？

Question

我找到了一些文章，描述了如何通过/etc/security/limits.conf增加打开文件数量的限制，但我不明白这样做会产生什么影响。很多时候我看到人们将1024更新为2048。好吧，那些文件句柄一定会消耗内存或其他资源。为什么不增加到100000呢？打开文件会占用哪些资源呢？

关于如何增加限制的问题：https://stackoverflow.com/questions/34588/how-do-i-change-the-number-of-open-files-limit-in-linux

- Adam

---

请注意，在Debian squeeze/wheezy上，/etc/security/limits.conf在系统启动时不起作用，详细解释请参考http://superuser.com/a/459183/31281和https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302079。 - ZaphodB

Answer 1

这是单个进程在同一时间内可以打开的文件数量的限制。套接字、管道和终端也计入其中。几乎没有任何软件能够同时处理超过大约20,000个打开的文件，所以将限制设置得更高是没有意义的。

- David Schwartz

---

太好了，谢谢。我明白这些都是限制，但我想知道它们是在保护什么。我们有一个托管着一些非常活跃的应用程序的服务器，已经接近了16k的限制，所以我想知道如果我们让它继续扩展会有什么影响。那么我会将注意力转向为什么我们有这么多该死的文件。再次感谢。 - Adam

@Adam 如果数量增加是因为他们合理地使用更多的网络连接或文件，那么你可以继续增加它，至少直到达到软件处理能力的限制。但如果存在文件描述符泄漏，那就需要进行调查和修复。 - David Schwartz

我不相信这是一个泄漏问题，因为在达到峰值后，通过lsof查看的打开文件数似乎又回落到更适中的数字。感谢您的反馈。 - Adam

@Adam 这强烈暗示着它是合理使用的，因此提高限额是合适的。 - David Schwartz

顺便问一下，当你说"没有任何现有的软件"时，是指没有现代操作系统吗？ - Adam

操作系统可以，问题出在应用程序上。 - David Schwartz

好的，关于用户的参考，我们已经将限制增加到32k，并且Jenkins在构建过程中使用它们没有问题。我仍然不完全理解这个限制是什么或者为什么默认值如此低，但我还没有找到实际的硬件限制。 - Adam

来自未来的更新，Nexus 3现在具备检查功能，并会提醒您如果内存少于64k。 - Adam

注意，一些像Kafka这样的高IO过程可能需要更多的资源。例如，典型的文件描述符（nofile）最大值建议设置在10万以上。更多信息请参考此链接。 - xmar

20K这个数字现在已经严重过时了。 :) - David Schwartz

答案已經過時了，不妨看看現代的數據庫——例如 ClickHouse。我認為它需要更新。 - Sonique

ElasticSearch建议将生产环境的nofile限制设置为65,535。 - James McGuigan

Answer 2

就像上面提到的，nofiles的值取决于"/proc/sys/fs/nr_open"，而ulimit使用setrlimit()来设置资源限制。

- Prashant Lakhera