okToAccept: WARNING! Your cache is running out of filedescriptors

在squid的实际应用过程中，我碰到这样一个现象：

环境： centos6 32bit, squid 3.1.rpm

用户在上网时，明明带宽还空闲很多，但上网奇慢无比。服务器资源的使用也不是很紧张，但就是不知从何下手去解决，我以为是squid版本性能问题，于是改为squid2.7编译安装，可还是没有解决这个问题。无奈之下，想来squid的应用也有好多年了，应该代理千人上网没有问题， 难道要进行传说中的优化。以前安装应用服务，一般都按照默认参数，还没碰到过这类问题。
那就优化一下试试，查找相关资料及查看日志，一个被我忽略的日志文件找到cache.log,其中有这样的警告：2011/11/01 15:32:04| client_side.cc(2980) okToAccept: WARNING! Your cache is running out of filedescriptors #filedescriptors为文件描述符
哇噻，难道就是这个问题引起的，怀着激动的心情上网搜搜，有了以下解决方案：
Squid 在高负载下，需要大量的内核资源。特别的，你需要给你的系统配置比正常情况更高的文件描述符和缓存。文件描述符的限制通常很恼人。你最好在开始编译squid 之前来增加这些限制的大小。因为squid 的工作方式，文件描述符的限制可能会极大的影响性能。当squid 用完所有的文件描述符后，它不能接收用户新的连接。也就是说，用完文件描述符导致拒绝服务。直到一部分当前请求完成，相应的文件和socket 被关闭，squid 不能接收新请求。当squid发现文件描述符短缺时，它会发布警告。
通常情况下，Squid 默认为1024（跟着系统的限制走）个文件描述，一般情况已经够用。当系统高度繁忙时，肯能会用到4096个或更大。在编译 Squid 前推荐将描述符更改至，系统限制级别的 2～3倍。

修改的方法：
#通常情况下，应当将FileDescriptor至少设置为ulimit -n的2倍。
第一步：将ulimit -n的数量先加大：ulimit -HSn 32768。这个通常有几种方法：
1.直接执行：ulimit -HSn 32768，但重启OS后会失效
2.编辑/etc/rc.local，加入一行：ulimit -HSn 32768，重启后生效
3.编辑/etc/security/limits.conf，重启后生效：
* soft nofile 4096
* hard nofile 4096
说明：* 代表针对所有用户
noproc 是代表最大进程数
nofile 是代表最大文件打开数
4.编辑/etc/init.d/squid，在该脚本执行start()动作前，加入“ulimit -HSn 32768”

第二步：将squid的filedescript1ors增大，这个通常也有几种方法：

1.编译安装squid时，在执行configure前，先在命令行执行一次：ulimit -HSn 32768

2.编译安装squid时，在执行configure时，加上--with-filedescriptors=32768 参数 (当然是加上参数来的靠谱)
[root@SQUID-SH squid-2.7.STABLE9]# ./configure --prefix=/opt/squid2.7/ --enable-storeio="null ufs" --with-maxfd=6553