我们在Dell 1955上运行RHEL 5：
CPU：2 x双核2.66GHz 4MB 5150 / 1333FSB
RAM：8GB RAM
HDD：2 x 160GB 2.5“ SATA硬盘
我检查了文件描述符限制，并将其设置为1024.考虑到我们的应用程序可能具有大约1000个传入连接以及1000个传出连接，这似乎很低，更不用说任何需要打开的实际文件了。
我的第一个念头是只是将ulimit -n参数增加几个数量级，然后重新运行测试，但是我想知道将此变量设置得太高的任何潜在后果。
是否有任何最佳做法除了确定理论上我们的软件可以打开多少个文件描述符外，还需要进行其他设置吗？
#1 楼
这些限制来自多个“正常”用户（而非应用程序）共享服务器的时间，我们需要保护他们避免使用过多资源的方法。对于高性能服务器而言，它们非常低并且我们通常将它们设置为很高的数量。 （大约24k）如果需要更大的数字，还需要更改sysctl file-max选项（通常在ubuntu上限制为40k，在rhel上限制为70k）。
设置ulimit：
# ulimit -n 99999
Sysctl最大文件：
#sysctl -w fs.file-max=100000
而且，非常重要，您可能需要检查您的应用程序是否具有内存/文件描述符泄漏。使用lsof可以查看所有内容是否有效。不要尝试更改系统以解决应用程序错误。
#2 楼
cat /proc/sys/fs/file-nr
在“高负载”情况下，始终可以查看正在使用的文件描述符。
-这取决于您在做什么。
评论
当上面的命令向我显示8288 0 793377时，我认为143000足够好！
– Sridhar Sarnobat
17-10-17在3:55
#3 楼
如果文件描述符是tcp套接字等，那么您将冒用完套接字缓冲区和其他内核对象的大量内存的风险。此内存将不可交换。但是，否则，不可以，原则上应该没有问题。请查阅内核文档，以尝试确定将使用多少内核内存和/或对其进行测试。
我们运行的数据库服务器打开了约1万个文件描述符（通常在真实磁盘文件上），而没有主要问题，但它们是64位并且有ram负载。
ulimit设置是针对每个进程的，但也存在系统范围的限制（我认为默认为32k）
#4 楼
我个人不了解任何最佳做法。取决于系统功能，这有些主观。请记住，您看到的1024是每个用户的限制，而不是系统范围的限制。请考虑在此系统上运行多少个应用程序。这是唯一的吗？运行此应用程序的用户还有其他事情吗？ （即IE，您是否有人使用此帐户登录并运行可能会失控的脚本？）
鉴于此框仅在运行该应用程序，而运行该应用程序的帐户仅用于该目的，我认为按照您的建议增加您的限额没有什么害处。如果是内部开发团队，请征询他们的意见。如果来自第三方供应商，则他们可能有特定要求或建议。
评论
@Grahamux系统专用于此应用程序，运行该应用程序的用户仅运行此应用程序。我是公司内部开发团队的一员，所以那里没有帮助。
–凯文
09年7月31日在23:20
限制不是针对每个用户，而是针对每个进程。参见unix.stackexchange.com/questions/55319/…
–胎蛋白
2014年3月28日15:39
#5 楼
在我看来，这是“在开发环境中进行测试”最好回答的问题之一。我记得几年前，当您将Sun弄得一头雾水时，他就感到紧张，但并不那么紧张。当时的限制也是1024，所以令我惊讶的是，现在Linux也是如此，似乎应该更高。我发现以下链接很有教育意义谷歌搜索您的问题的答案：
http://www.netadmintools.com/art295.html
这也是：
https://stackoverflow.com/questions / 1212925 / on-linux-set-maximum-open-files-to-unlimited-possible
评论
@sucuri谢谢。我们肯定担心资源泄漏，但事实并非如此。我们一直在观察lsof和netstat，尽管数量很高，但它们并没有持续增长，而是在扩张和收缩。我希望如果发生泄漏，打开的套接字或描述符的数量将随着时间的推移继续增加。
–凯文
09年8月1日在13:59
ulimit限制不是针对每个用户，而是针对每个进程！参见unix.stackexchange.com/questions/55319/…并且fs.file-max设置是针对整个服务器的（因此所有进程在一起）。
–胎蛋白
2014年3月28日15:44