okToAccept: WARNING! Your cache is running out of filedescriptors

精选转载

gy19910601 2013-09-06 10:22:36

文章标签 linux-squid 文章分类 运维

在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 是代表最大文件打开数