高容量系统的实用最大打开文件描述符（ulimit -n）

我们最近开始对我们的应用程序进行负载测试，并注意到它在大约24小时后就耗尽了文件描述符。

我们在Dell 1955上运行RHEL 5：

CPU：2 x双核2.66GHz 4MB 5150 / 1333FSB RAM：8GB RAM硬盘：2 x 160GB 2.5“ SATA硬盘

我检查了文件描述符限制，并将其设置为1024。考虑到我们的应用程序可能具有大约1000个传入连接以及1000个传出连接，这似乎很低。更不用说任何需要打开的实际文件了。

我的第一个想法是将ulimit -n参数增加几个数量级，然后重新运行测试，但是我想知道将此变量设置得太高的任何潜在后果。

除了弄清楚我们的软件理论上可以打开多少文件描述符之外，是否还有其他最佳实践来设置？

这些限制来自多个“正常”用户（而非应用程序）共享服务器的时间，我们需要保护他们避免使用过多资源的方法。

对于高性能服务器，它们的数量非常低，我们通常将它们设置为很高的数量。（大约24k）如果您需要更大的数字，还需要更改sysctl file-max选项（通常在ubuntu上限制为40k，在rhel上限制为70k）。

设置ulimit：

# ulimit -n 99999

Sysctl最大文件：

#sysctl -w fs.file-max=100000

同样，而且非常重要，您可能需要检查应用程序是否存在内存/文件描述符泄漏。使用lsof可以查看所有内容是否有效。不要尝试更改系统以解决应用程序错误。

你总是可以

cat /proc/sys/fs/file-nr

在“高负载”情况下，查看正在使用多少文件描述符。

至于最大数量-它仅取决于您在做什么。

如果文件描述符是tcp套接字等，那么您就有冒用套接字缓冲区和其他内核对象的大量内存的风险。该内存将不可交换。

但是否则，没有，原则上应该没有问题。请查阅内核文档以尝试确定它将使用和/或测试多少内核内存。

我们运行的数据库服务器打开的文件描述符大约有1万个（主要在真实的磁盘文件上），没有大问题，但是它们是64位的，并且具有ram负载。

ulimit设置是针对每个进程的，但是也存在系统范围的限制（我认为默认为32k）

我个人不了解任何最佳做法。这取决于系统功能，有些主观。

请记住，您看到的1024是每个用户的限制，而不是系统范围的限制。请考虑您在该系统上运行了多少个应用程序。这是唯一的吗？运行此应用程序的用户还有其他事情吗？（即，您是否有人使用此帐户登录并运行可能会失控的脚本？）

鉴于此框仅在运行该应用程序，并且运行该应用程序的帐户仅用于该目的，因此，按照您的建议增加限额没有什么害处。如果是内部开发团队，请征询他们的意见。如果来自第三方供应商，则他们可能有特定的要求或建议。

在我看来，这似乎是“在开发环境中进行测试”最好回答的问题之一。我记得几年前，当您对此感到困惑时，Sun感到紧张，但并不那么紧张。当时的限制也是1024，所以我对Linux的限制感到惊讶，似乎应该更高。

当我搜寻您问题的答案时，发现以下链接具有教育意义：http : //www.netadmintools.com/art295.html

而且这个也是：https : //stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible