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

Question

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

我们在 Dell 1955 上运行 RHEL 5：

CPU：2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB RAM：8GB RAM HDD：2 x 160GB 2.5" SATA 硬盘

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

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

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

Answer 1

这些限制来自多个“普通”用户（不是应用程序）共享服务器的时代，我们需要一些方法来保护他们免于使用过多资源。

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

设置ulimit：

# ulimit -n 99999

Sysctl 最大文件：

#sysctl -w fs.file-max=100000

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

Answer 2

你总是可以

cat /proc/sys/fs/file-nr

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

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

Answer 3

如果文件描述符是 tcp 套接字等，那么您可能会为套接字缓冲区和其他内核对象占用大量内存；这个内存是不可交换的。

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

我们在打开大约 10k 个文件描述符的情况下运行数据库服务器（主要是在真实的磁盘文件上），没有大问题，但它们是 64 位的，并且有大量的内存。

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