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

Question

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

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

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

也许有人可能会给出其他高端生产服务器的想法？最大化潜在的同时连接数(文件描述符)的“标准”是什么？如果能深入了解如何为 Linux 系统最大化文件描述符，我们将不胜感激。

Answer 1

你有很多限制。

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

• 应用速度。在这种规模(相当低)下，每个请求 1 毫秒的应用程序延迟将花费将近两分钟的时间来在最佳条件下处理 100,000 个请求。

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

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

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