it-swarm.cn

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

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

我们在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参数增加几个数量级,然后重新运行测试,但是我想知道将此变量设置得太高的任何潜在后果。

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

77
Kevin

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

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

设置ulimit:

# ulimit -n 99999

Sysctl最大文件:

#sysctl -w fs.file-max=100000

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

73
sucuri

你总是可以

cat /proc/sys/fs/file-nr

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

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

15
Ben Lessani - Sonassi

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

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

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

Ulimit设置是针对每个进程的,但也存在系统范围的限制(我认为默认值为32k)

6
MarkR

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

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

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

2
Grahamux

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

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

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

1
Kyle Hodgson