五一的时候yycrazy本来准备对服务器上的应用进行一次分离操作，但是由于极差的网络性能铩羽而归。自从五一过后服务器一直处于极度不稳定状态：系统不定期并且毫无征兆的所有phpcgi进程突然卡死导致CPU负载飙升并导致全站所有动态内容访问很慢且最终全线奔溃。

一开始找了很多资料尝试了很多方法都没有明显的好转，因为没有任何一定的触发条件，并且所有等级的日志和监控都无法记录任何蛛丝马迹，所以一时很难做出准确判断。无意之中在网上看到有TX反应Discuz X 1.5在nginx+php-cgi环境下使用manyou应用的时候很容易导致php-cgi进程高负载运作大量消耗CPU资源，于是尝试将开启的Discuz X1.5的manyou应用关闭，发现问题有很大的缓解，本来以为已经解决了，但是第二天凌晨时再度出现毫无征兆的所有phpcgi进程突然卡死让我无奈地之后从更底层的角度去考录解决的办法。

经过漫长的排查与测试最终发现问题出在/boot/loader.conf中的设置上，一开始安装FreeBSD的时候顺手copy了之前的一份优化过的loader.conf配置的一部分，里面有一个参数 kern.ipc.nmbclusters="0"，本来只是将nmbclusters设置成无限制，但是问题就出在只copy了一部分：因为kern.ipc.nmbclusters被设置成0的情況下，net.inet.tcp.reass.maxsegments 参数也跟着一同被设置成 0了。net.inet.tcp.reass.maxsegments被设置成0之后在有大量 TCP out-of-order封包的网络情况下，FreeBSD的性能将会变得极差而且整个系统会非常的脆弱，在出现问题的时候用netstat查看连接信息可以发现packets discarded due to memory problems的计数相当之多而 TCP out-of-order的计数永远为0。

解决方法：

1、将net.inet.tcp.reass.maxsegments设置成默认值1600；
2、设置 kern.ipc.nmbclusters为一个非0的数值，例如我将kern.ipc.nmbclusters="102400"添加到了/boot/loader.conf文件中。

修改成功后重启FreeBSD，至少目前没有再出现过一次系统毫无征兆的所有phpcgi进程突然卡死的情况了……

---

在漫长的排查过程中又发现了一个有趣的情况：记得之前FreeBSD在ESXi下时间会跑慢的时候是通过向loader.conf文件添加了hint.apic.0.disabled="1"以关闭中断和kern.hz=100调整刷新率来修正时间问题，这次尝试着将kern.hz调成10重启之后发现在ESXi中的FreeBSD8性能变得奇好……不过问题是FreeBSD8中的时间大概是真实时间的2~4倍，最终将kern.hz调成了50时间不跑偏而且性能和响应速度相对于之前要好很多。看起来像kern.hz在多用户多进程的情况下调低更好，桌面系统单用户的情况下调高更好。

关于kern.hz在FB的论坛上有这么一段话供参考

这是一个已知的性能问题。虚拟机的中断是经过虚拟化软件来进行处理的，而不是直接的硬件中断；当 guest OS 定时器精度较高时，如 1000 Hz （这是新版内核的默认情况，早期内核的精度是 100 Hz 甚至 10 Hz），直接在硬件上运行操作系统通常是没有问题的，但虚拟机将花费较多的 host CPU time 来处理定时器对应的系统中断，因此用户会发现 CPU 占用变高，甚至在“空闲”时也能达到 50% ~ 100%；解决的办法是降低 guest OS 定时器的精度，以牺牲精度来换取性能。 如果您的 host CPU 支持硬件虚拟化技术（Intel VT 或 AMD-V），您还可以试着打开 VirtualBox 的 hardware virtualization，这应该可以继续改善虚拟机的性能。

参考文章