我有一个生产鱿鱼服务器，有一些问题提供内容和报告，它是文件描述符。 我成功地能够从1024（默认）增加到4096，它似乎解决了我的日志中的错误。 我仍然看到响应代码0和0字节收到一些未caching的调用，这导致我相信，在峰值（启动风暴），我的文件描述符计数仍然太低。
我已经阅读了一些post，设置可以设置为高达像24K，40K，甚至70K。 由于这是一个专用的鱿鱼盒，我不担心其他进程/用户竞争文件描述符在系统范围内，但我真的想知道什么是最好的做法是粗略计算我应该configuration多less个文件描述符为ulimit -n。
在我的configuration中，我有最多3000个客户端TCP连接，最多3000个服务器端TCP连接，以及一些默认configuration在squid config（cache.log，squid.log）中的日志文件。 这是简单的说，我应该把我的ulimit -n 3000 + 3000 + 2 +（一些间接费用）？ 对于缺乏关于此事的文档，我可能会将其设置为24k，以便永远不必处理它，但我更喜欢有一个最佳实践公式可以遵循 – 就像使用apache2，您可以计算多less请求所需的内存希望能够同时处理。
编辑：忘了提及，我不写这些caching的文件到磁盘，他们留在内存中。 这是几百个文件（总共<5 MB）的网站，是唯一通过这个被加载的页面，所以这就是为什么我省略了磁盘读/写文件描述符。
在最坏的情况下，每个向squid服务器发送请求都需要三个文件描述符;
然后有开销，包括日志文件，任何进程间通信，例如助手和空闲连接。 所以作为一个粗略的估计，每个传入的TCP连接需要三个文件描述符，然后考虑任何开销。
在寻找更多“最佳实践”信息的search中，Nasoo已经死于如何计算应该configuration的打开文件的数量。 我发现浏览器并行处理下载文件是错综复杂的，所以3000个客户端实际上每个大约25-30个套接字来下载完整的网页和dynamic内容。 其中一些取决于浏览器如何并行下载，以及javascript API如何处理下载dynamic内容。
所以，虽然我不能准确地确定一个正确的数字没有吨额外的testing，我也绊倒手册，指出可以为每4MB的RAM设置256个文件句柄。 所以这应该是绰绰有余的，甚至是我为这个盒子的8GB内存的一半将是矫枉过正的。
http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec72.html
编辑：我也开始通过cronjob每分钟一次logging文件描述符使用情况到RRD文件。 这是一个非常基本的bash脚本，它可以将所有日志logging下来，并且可以生成相当方便的graphics，而不需要监视服务器或任何东西。 如果有人对此感兴趣，请告诉我，我会从中解脱出来。