Linux中文件描述符的理论限制

Question

我正在运行一个带Squid的专用代理服务器，我试图了解服务器可以处理的最大连接数。我已经意识到这归结为Linux机器上的可用文件描述符。

我发现了大量有关增加最大文件描述符的信息，但我想找出理论上的最大值。根据StackOverflow问题"Why do operating systems limit file descriptors?"，它归结为可用的系统RAM，这很有意义。

现在，考虑到我有多少RAM可用，如何确定操作系统文件描述符的最大值？显然仍然允许系统稳定运行的一些价值。

也许有人可能对其他高端生产服务器有所了解？最大化同时连接（文件描述符）的潜在数量的“标准”是什么？任何有关如何为Linux系统最大化文件描述符的见解都将非常感激。

Answer 1

你有很多限制。

• 复用。如果您的应用程序使用了一个像样的后端，这应该不是问题。 Libev声称在100,000个文件描述符处复用350us延迟。

• 申请速度。对于每个请求，该规模的1ms应用程序延迟（非常低）在最佳条件下服务100,000个请求将花费将近两分钟。

• 带宽。根据您的应用程序和协议效率，这可能是一个问题。你说它是一个squid代理...如果你是代理网站：没有缓存请求网站的客户端可以接收从几百KB到几MB的任何地方。如果每个客户端的平均整页请求数为500KB，那么每秒2000个请求的最大千兆位连接数就会达到最大值。这可能是您的限制因素。

2000个文件描述符是一个相当小的数量。我已经看到像Python这样的语言中的简单应用程序可以在单个处理器核心上扩展到超过3000个活动连接而没有不良延迟。

您可以使用在多台客户端计算机上运行的apachebench等软件测试您的squid代理，以获得一些实际数字。很容易将文件描述符限制达到2000以上，看看会发生什么，以及之后是否会产生影响。