五一的时候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。

阅读全文>>

母系统为ESXi 3.5的服务器，上面跑着的一台客户机FreeBSD，不知因为什么原因上面的十一个快照紊乱了，记得以前强行删除所有快照的时候可能会遇到这个情况。明白问题状态之后第一时间将客户机关闭，打开ESXi的命令行控制台，相应的文件夹内有FreeBSD8.vmdk，FreeBSD8-0000xx.vmdk等文件，FreeBSD8.vmdk为镜像之前最基本的硬盘，FreeBSD8-0000xx.vmdk是每个快照之后的硬盘镜像。

这是在等PORTS更新和编译的事件中匆匆写的，有些混乱。

网上关于ESXi下虚拟硬盘损坏该怎么修复的相关文档比较少，幸好找到了一篇跟今天遇到的情况类似的文章，很勉强地将出问题的硬盘恢复到了第八个快照，9、10、11快照都挂掉了，大概过程如下：

阅读全文>>

尝试过安装VMware tools、修改grub、定期网络对时等方案，都不太靠谱，时间依旧会慢

故障分析
这种问题通常都是由于ESXi的时间戳（TSC）频率是本地APIC时间的1半的倍数，而虚拟机并不在这个影响范围内；

解决方案
可以通过修改虚拟机的.vmx文件添加如下信息：
...

阅读全文>>

由于特殊的网络环境和资源限制等原因，之前在ESXi的服务器上装了一个软路由供给其他的VPS客户机上网：刚装上时用着挺好，但是过一段时间（不恒定）就会出现无法提供NAT服务，甚至无法被Ping通，总之经过了一段时间都没有找到很好的解决方法，最后只能设置每隔一段时间重启一次软路由。由于几次在FreeBSD的messages信息中看到了软路由在莫名其妙地更新自己的MAC地址，所以一直都怀疑是这个导致的问题。

今天设置ESXi的时候发现了ESXi可以拒绝更新MAC地址，虽然暂时还不能非常确定到底是不是MAC变动导致的问题，但是值得尝试一下：

阅读全文>>