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

前端之家收集整理的这篇文章主要介绍了如何计算专用squid服务器的ulimit -n(文件描述符)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个生产鱿鱼服务器,它有一些问题提供内容和报告它是文件描述符.我成功地将它从1024(默认)增加到4096,它似乎解决了我在日志中的错误.对于一些未缓存的调用,我仍然看到响应代码0和0字节,这使我相信在峰值卷(启动风暴)中我的文件描述符计数仍然太低.

我已经阅读了一些帖子,设置可以设置为24k,40k甚至70k.由于这是一个专用的鱿鱼盒,我不担心其他进程/用户在系统范围内竞争文件描述符,但我真的想知道最佳做法是粗略计算我应该配置多少个文件描述符对于ulimit -n.

在我的配置中,我最多有3000个客户端TCP连接,最多3000个服务器端TCP连接,以及一些默认配置在squid配置(cache.log,squid.log)中的日志文件.是不是说我应该将我的ulimit -n设置为3000 3000 2(一些开销金额)?由于缺乏关于此问题的文档,我可能会将其设置为24k,以便永远不必处理它,但我更喜欢使用最佳实践公式 – 就像使用apache2一样,您可以计算需要多少请求的内存希望能够同时处理.

编辑:忘了提到我没有把这些缓存的文件写入磁盘,它们留在内存中.这是几百个文件(总共<5 MB)的网站,这是唯一一个通过它加载的页面,所以这就是我省略了磁盘读/写文件描述符的原因.

解决方法

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

>客户端连接的描述符
>另一个用于服务器端连接,以防它未被缓存.
>第三个文件读取命中或缓存未命中.

然后存在包括日志文件,任何进程间通信(例如,助手和空闲连接)的开销.因此,粗略估计每个传入的TCP连接需要三个文件描述符,然后将任何开销考虑在内.

猜你在找的Linux相关文章