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

Question

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

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

现在，鉴于我有多少可用 RAM，我如何确定操作系统文件描述符的最大值？一些显然仍然可以让系统稳定运行的值。

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

Answer 1

你有很多限制。

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

• 应用程序速度。在这种规模（相当低）的情况下，每个请求 1 毫秒的应用程序延迟几乎需要两分钟才能在最佳条件下处理 100,000 个请求。

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

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

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