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

Question

3

我正在运行一个带有Squid的专用代理服务器，想要了解服务器可以处理的最大连接数。我意识到这取决于Linux机器上可用的文件描述符。

我找到了很多关于增加最大文件描述符的信息，但我想找出理论最大值。根据StackOverflow问题"为什么操作系统限制文件描述符?"，这取决于可用的系统RAM，这很有道理。

现在，鉴于我可用的RAM量，如何确定操作系统文件描述符的最大值？某个值显然仍将使系统保持稳定。

也许其他高端生产服务器会有人有想法？达到最大同时连接数（文件描述符）的“标准”是什么？任何关于如何将Linux系统的文件描述符最大化的见解都将不胜感激。

- Michelle

3

在你耗尽描述符之前，你会遇到其他资源问题。 - spraff

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- lunixbochs · Accepted Answer

您有许多限制。

复用。如果您的应用程序使用合适的后端，这不应该是一个问题。Libev声称，在拥有100,000个文件描述符时，延迟只有350微秒。
应用程序速度。在那种规模下（相当低），每个请求1毫秒的应用程序延迟将花费近两分钟来服务100,000个请求。
带宽。这可能会因您的应用程序和协议效率而异。您说这是一个Squid代理...如果您正在代理网站：一个没有缓存的客户端请求网站时，可能会收到几百KB到几MB的数据。如果每个客户端的平均完整页面请求为500KB，则在2000个请求/秒时，您将耗尽整个千兆连接。这可能是您的限制因素。

2000个文件描述符是一个相当少的数量。我曾经看到过像Python这样的简单应用能够扩展到单个处理器核心上的3000个活动连接，而没有出现性能问题。

您可以使用诸如ApacheBench之类的软件在多个客户端计算机上测试Squid代理以获取一些实际数字。很容易将您的文件描述符限制提高到2000+，然后观察是否会有任何差异。