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


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

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

除了确定我们的软件理论上可以打开多少个文件描述符之外,是否有任何最佳实践来设置这个?


69
2017-07-31 22:35






答案:


这些限制来自多个“普通”用户(不是应用程序)共享服务器的时间,我们需要保护他们免于使用太多资源的方法。

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

设置ulimit:

# ulimit -n 99999

Sysctl max文件:

#sysctl -w fs.file-max=100000

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


70
2017-08-01 13:08



@sucuri谢谢。我们肯定担心资源泄漏但似乎并非如此。我们一直在关注lsof和netstat,虽然数字很高,但他们并没有继续增长,他们扩张和收缩。我希望如果发生泄漏,开放套接字或描述符的数量会随着时间的推移而持续增长。 - Kevin
该 ulimit 限制不是每个用户,而是每个进程!看到 unix.stackexchange.com/questions/55319/...  而且 fs.file-max 设置是为整个服务器(所有进程一起)。 - Tonin


你可以永远

cat /proc/sys/fs/file-nr

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

至于最大值 - 它只取决于你在做什么。


13
2018-05-18 12:22



在上面的命令告诉我的时候,我在想143000就够了 8288 0 793377! - Sridhar-Sarnobat


如果文件描述符是tcp套接字等,则可能会浪费大量内存用于套接字缓冲区和其他内核对象;这个内存不可交换。

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

我们运行的数据库服务器打开了大约10k个文件描述符(主要是在真正的磁盘文件上)而没有出现重大问题,但是它们是64位且有大量内存。

ulimit设置是按进程进行的,但也存在系统范围的限制(我认为默认为32k)


6
2017-08-01 12:27





我个人并不了解任何最佳做法。根据系统功能,这有点主观。

请记住,您看到的1024是每用户限制而不是系统范围的限制。考虑您在此系统上运行的应用程序数量。这是唯一一个吗?运行此应用程序的用户是否正在执行其他操作? (IE你有人使用这个帐户登录并运行可能会逃跑的脚本吗?)

鉴于该框仅运行此应用程序,并且运行该应用程序的帐户仅用于此目的,我认为如您所建议的那样增加限制没有任何害处。如果它是一个内部开发团队,我会征求他们的意见。如果它来自第三方供应商,他们可能有特定的要求或建议。


2
2017-07-31 22:53



@Grahamux系统专用于此应用程序,运行应用程序的用户仅运行此应用程序。我是内部开发团队的一员,所以没有帮助。 - Kevin
限制不是每个用户,而是每个进程。看到 unix.stackexchange.com/questions/55319/... - Tonin


在我看来,这是“在开发环境中测试它”最能回答的问题之一。我记得几年前,当你搞砸了太阳时,太阳会紧张,但不是那么紧张。它当时的限制也是1024,所以我有点惊讶地发现它现在对Linux来说是相同的,似乎它应该更高。

当我搜索你的问题的答案时,我发现以下链接教育: http://www.netadmintools.com/art295.html

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


1
2017-08-01 00:51