☰

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

tag-icon • tag-icon linux java ulimit max-file-descriptors
高容量系统的实际最大打开文件描述符 (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 参数增加几个数量级，然后重新运行测试，但我想知道将此变量设置得太高可能产生的后果。

除了确定我们的软件理论上可以打开多少个文件描述符之外，还有什么最佳实践可以设置这个吗？

答案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

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

至于最大值 - 这取决于您正在做什么。

答案3

如果文件描述符是 tcp 套接字等，则可能会冒着为套接字缓冲区和其他内核对象使用大量内存的风险；这些内存是不可交换的。

但除此之外，原则上应该没有问题。查阅内核文档以尝试确定它将使用多少内核内存，并/或对其进行测试。

我们运行数据库服务器，打开了大约 10k 个文件描述符（大部分在真实磁盘文件上），没有出现大问题，但它们是 64 位的并且具有大量 RAM。

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

答案4

在我看来，这个问题最好用“在开发环境中测试”来回答。我记得几年前 Sun 在你搞砸这件事时很紧张，但没那么紧张。当时它的限制也是 1024，所以我有点惊讶地发现现在 Linux 的限制也一样，似乎应该更高。

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

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

相关内容