(再不写blog就要荒到长出草来了。。)

squid 2.6 出来有那么一段时候了,一直没有时间试验。最近终于找到了一些时间,于是决定将某站的squid升级上去玩玩。

2.6 的 RPM 只有 fedora development 里面才有(我是非常懒的,RPM基本都是拿现成的来用),好在依赖关系不是非常复杂,简单修改了一下去掉了一些依赖比较多的认证模块比如ntlm和ldap之类,FC6的RPM就在FC3上面build出来了。

RPM有了,但是暂时还不能升级,因为squid之王说过配置文件格式变化了,原来给懒人使用的 http_accel 系列都去掉了,统一进了 cache_peer 里面,这个本来是很好的想法,但是 cache_peer 这语法有个局限,不能区分同一台主机上面的多个端口。squid2.6为了保持和以前cache_peer语法的兼容性,加了一个 name 的参数来搞定这个。搞的整个语法看起来很难受。其实依我说,这次反正都已经改了好多了,不如借此机会再规范化一下算了。

关于 squid 2.6 升级的配置细节,可以参考这里

闲话少说,直接 rpm -U 上去,升级就算完成了。看起来访问是没有什么问题。而且 CPU 占用特别低。以前都保持在 30% 以上,现在最强的时候也只有 1x%。不禁心里暗爽,这新东西还是很好的嘛。

几个小时以后,偶尔上了一下 web 发现相当慢,在 dmesg 里面发现了很多 Drop request 的纪录,知道坏事了。重起一下只能顶几分钟,请求到 450 QPS 的时候一定会开始丢请求。只好恢复成 2.5,于是一切都恢复正常了。

虽然 2.5 还是可以用,但是心里面还是很不甘心的,于是找squid之王又要了一个编译参数,禁止掉fc6 rpm里面的无聊patch,禁止掉coss存储之类用不到的破东西。重新编译了一下 squid ,再次换回来,问题依旧。

最后这次 squid 升级以失败告终,但是我还是不太明白发生了什么事情。猜测了几种可能。

1:squid 2.6 的新网络代码有什么问题。不能够及时 accept 请求,而是阻塞在其他什么操作里面了。
2: squid 2.6 从 3.0 移植过来的网络代码太高效了,导致把请求总是可以迅速发送到后端 web server,对 webserver 造成了太大冲击。

谁还有用 squid 2.6 的,有没有遇到类似的问题啊?