FreeBSD在ESXi中性能极差

五一的时候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,这应该可以继续改善虚拟机的性能。

参考文章


「倘若有所帮助,不妨酌情赞赏!」

Holmesian

感谢您的支持!

使用微信扫描二维码完成支付


相关文章

发表新评论