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

Question

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

我们正在戴尔1955上运行RHEL 5：

CPU: 2x双核2.66GHz 4MB 5150 /1333 8GB :8GB RAM HDD: 2×160 8GB 2.5“SATA硬盘驱动器

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

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

除了计算出我们的软件理论上可以打开多少个文件描述符之外，还有什么最好的方法来设置它吗？

Answer 1

这些限制来自多个“正常”用户(而不是应用程序)共享服务器的时候，我们需要保护他们不使用太多资源的方法。

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

设定上限：

# ulimit -n 99999

Sysctl max文件：

#sysctl -w fs.file-max=100000

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

Answer 2

你可以一直

cat /proc/sys/fs/file-nr

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

至于最大限度，这取决于你在做什么。

Answer 3

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

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

我们运行数据库服务器时，打开了~ 10k文件描述符(大部分是在真正的磁盘文件上)，没有什么大问题，但是它们是64位的，并且有大量的ram。

U极限设置是每个进程，但也有一个系统范围的限制(我认为默认情况下是32k)。