squid的默认打开的最大的文件描述符为1024，但访问量大的话就不够用了，不够用时，squid的性能骤降，今天是碰到第二回了，解决办法如下（Linux系统下）：

squid 2.6的版本的话编译时添加参数--with-maxfd=63355

这里63355可以定制。光设置参数还不行，squid系统时还需要做两个操作

echo  63355 > /proc/sys/fs/file-max

ulimit -Hn 63355

然后启动squid，（注意这些操作包括squid的启动都需要在一个shell下）

如何查看squid具体用了多少文件描述符呢，很简单，运行

/path/squid/bin/squidclient -p 80 -U manager -W squidstats mgr:info

输出结果中:

File descriptor usage for squid:
        Maximum number of file descriptors:  63355
        Largest file desc currently in use:  4474
        Number of file desc currently in use: 2335

表示最大的文件描述符为63355，当前使用的最大的文件描述符是4474，总共在使用的有2335个。

公司的服务器似乎越来越趋于稳定了,今天突然报了 open files limit...原来linux默认的文件描述符1024(ulimit -a命令查看)被用光了,为了增大文件描述符号,说要编译内核才行,今天研究了半天,居然没成功,后来干脆,用 ulimit -HSa 65536 (1MB64个文件描述符)似乎也生效,这里特别需要注意的地方,别忘了将上面一句加入到/etc/profile里面去,然后用lsof -p JAVA_PID|wc -l 查看jboss似乎已经可以跑到了1758.

附:
文件描述符是一个简单的整数，用以标明每一个被进程所打开的文件和socket。第一个打开的文件是0，第二个是1，依此类推。Unix 操作系统通常给每个进程能打开的文件数量强加一个限制。更甚的是，unix 通常有一个系统级的限制。

因为squid 的工作方式，文件描述符的限制可能会极大的影响性能。当squid 用完所有的文件描述符后，它不能接收用户新的连接。也就是说，用完文件描述符导致拒绝服务。直到一部分当前请求完成，相应的文件和socket 被关闭，squid 不能接收新请求。当squid发现文件描述符短缺时，它会发布警告。

在运行./configure 之前，检查你的系统的文件描述符限制是否合适，能给你避免一些麻烦。大多数情况下，1024 个文件描述符足够了。非常忙的cache可能需要4096或更多。在配置文件描述符限制时，我推荐设置系统级限制的数量为每个进程限制的2 倍。
2、怎么突破，具体方法？
先查看LINUX默认的文件描述符：
# ulimit -n
1024
我们用命令
ulimit -HSn 65536
来增大文件描述符，然后编译安装squid，
把ulimit -HSn 65536放到/etc/rc.d/rc.local让启动时加载。
以下为转载：
Linux

在Linux 上配置文件描述符有点复杂。在编译squid 之前，你必须编辑系统include 文件中的一个，然后执行一些shell 命令。请首先编辑/usr/include/bits/types.h 文件，改变__FD_SETSIZE 的值：
#define _ _FD_SETSIZE 8192

下一步，使用这个命令增加内核文件描述符的限制：
# echo 8192 >; /proc/sys/fs/file-max

最后，增加进程文件描述符的限制，在你即将编译squid 的同一个shell 里执行：
sh# ulimit -Hn 8192

该命令必须以root 运行，仅仅运行在bash shell。不必重启机器。

使用这个技术，你必须在每一次系统启动后执行上述echo 和ulimit 命令，或者至少在squid 启动之前。假如你使用某个rc.d 脚本来启动squid，那是一个放置这些命令的好地方。