如何计算专用 squid 服务器的 ulimit -n（文件描述符）

Question

我有一个生产 squid 服务器，它在提供内容时遇到了一些问题，并报告文件描述符不足。我成功地将其从 1024（默认值）增加到 4096，这似乎解决了日志中的错误。对于一些未缓存的调用，我仍然看到响应代码 0 和收到 0 字节，这让我相信，在峰值量（启动风暴）中，我的文件描述符计数仍然太低。

我已经阅读了一些帖子，可以将设置设置为 24k、40k 甚至 70k 等高值。由于这是一个专用的 squid 盒，我并不担心其他进程/用户会在整个系统范围内争夺文件描述符，但我真的很想知道粗略计算我应该为 ulimit -n 配置多少个文件描述符的最佳做法是什么。

在我的配置中，我最多有 3000 个客户端 TCP 连接、最多 3000 个服务器端 TCP 连接，以及一些在 squid 配置中默认配置的日志文件（cache.log、squid.log）。是不是只要说我应该将 ulimit -n 设置为 3000 + 3000 + 2 +（一些开销量）就行了？由于缺乏相关文档，我可能会将其设置为 24k，这样就不必处理它了，但我更喜欢遵循一个最佳实践公式 - 就像使用 apache2 一样，您可以计算出您希望能够同时处理多少个请求所需的内存。

编辑：忘记说了，我没有将这些缓存文件写入磁盘，它们留在内存中。这是一个只有几百个文件（总共不到 5 MB）的网站，是唯一通过此方法加载的页面，所以我省略了磁盘读/写文件描述符。

Answer 1

在最坏的情况下，每个对 squid 服务器的请求都需要三个文件描述符；

1. 客户端连接的描述符
2. 另一个用于服务器端连接，以防它没有被缓存。
3. 第三个用于表示文件读取命中或者缓存未命中。

然后是开销，包括日志文件、任何进程间通信（例如助手和空闲连接）。因此，粗略估计，每个传入 TCP 连接都需要三个文件描述符，然后将任何开销考虑在内。

Answer 2

在搜索更多“最佳实践”信息时，Nasoo 准确地指出了如何计算应配置的打开文件数。我发现浏览器处理并行下载文件的方式非常复杂，因此 3000 个客户端实际上每个客户端使用大约 25-30 个套接字来下载整个网页和动态内容。其中一些取决于浏览器如何并行下载以及 javascript API 如何处理下载动态内容。

因此，虽然我无法在没有大量额外测试的情况下准确确定一个合适的数字，但我也偶然发现了一本手册，上面说每 4MB RAM 可以设置 256 个文件句柄。所以这应该足够了，即使我为这个盒子配备的 8GB RAM 的一半也绰绰有余。

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html

编辑：我还开始通过 cronjob 每分钟将文件描述符使用情况记录到 RRD 文件中。这是一个非常基本的 bash 脚本，可以记录所有内容，您可以在没有监控服务器或任何东西的情况下生成非常方便的图表。如果有人对此感兴趣，请告诉我，我会从中总结出要点。