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

Question

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

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

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

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

Answer 1

你有很多限制。

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

• 应用速度。在每个请求的这种规模（相当低）下1ms的应用程序延迟将花费近两分钟的时间为最佳条件下的100,000个请求提供服务。

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

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

您可以使用像运行在多台客户端计算机上的apachebench这样的软件来测试您的squid代理，以获得一些实际的数字。将文件描述符限制提高到2000+并查看会发生什么，以及它是否会在以后发生变化，这是相当容易的。