一大组 squid 里面有两台相同配置的p3机器,  一台是 linux ,一台是 freebsd, 用 dns round-robin 轮转均衡,squid的配置完全相同,发现 linux 那台 TF 死活上不了 3MB, 同时很奇怪的 hitrate 也低,同时 freebsd 那台的 hitrate 就可以到 97%, TF 最大接近 4MB,于是想尽办法优化 linux 那台,升级到 as4, 自己编译 kernel, icc squid ,reiserfs , heap LFUDA, 开大memcache 大小同时改系统参数让 linux 尽量不 swap 等手段全都堆上来了,有大概 10% 的上升,但是还是赶不上那个 freebsd, 而且最重要的还是 hitrate 上不去,机组里面其他机器都是 freebsd , hitrate 都高。就在我即将放弃优化,得出来结论 freebsd 做 squid 优于 linux 的时候,福至心灵的去查看了一下这些机器的时间,结果发现linux 那台时间是准的,但是所有其他 freebsd 机器的系统时间齐刷刷的比标准时间晚了 10 分钟。。。

Update: 好像情况不完全是这样,调整时间以后,linux squid 的 RHR 有少许上升,还是比 freebsd 的低REQ/S 也有一定上升,和 freebsd 的那台经常很相近,但是 BHR 和 TF 还是没有上去,查看 cache 状态里面的对象数量倒是已经和 freebsd 那台差不多了,以前始终没有那么多。现在唯一的怀疑就是,这台disk cache积攒的过程中,不断调整替换算法,可能存储了很多小对象,影响了 BHR 和 TF,如果清除 disk cache 不知道有没有效果,但是线上我不是很敢弄了。

Update2: 最近实验表明,在门户网站这样访问相当密集,命中率非常高的情况下面,cache 替换算法基本没有什么太大用处,反而会占用cpu,导致每秒处理请求数量有少许下降。就最简单的 list based lru 足够。