无意中在Windows7 的命令提示符中输入ipconfig /all发现除了正常使用的本地连接zhiwai有数十条隧道适配器的本地连接，经过搜索得知这是win7在IPv6迁移过程中需要使用的一种或多种IPv6过渡技术：

    不过对于基本上不使用IPv6的用户这么多隧道适配器本地连接基本上没有任何用处，可以通过在CMD中执行以下命令进行关闭和移除：

...

阅读全文>>

 用Windows 7而且又偶尔会关心一下日志的TX可能会发现在网络情况不好的情况下经常可以发现类似下图的系统日志提示“在没有配置的 DNS 服务器响应之后,名称域名的名称解析超时”的记录。

原来这是由于Windows 7的一个叫做Network Connectivity Status Indicator (NCSI)的服务导致的：每当用户连接到网络时，Windows 7会向微软的一个域名发送访问请求，再通过访问http://www.msftncsi.com/ncsi.txt获得结果作为网络连接状况指示器，你能够看到“网络受限”的警告就是由这个服务产生的。

在这个过程中微软的DNS服务器可以记录来自Windows 7客户机的一些基本信息，接受访问的www.msftncsi.com所在的服务器也可以获得不少客户端的信息，数量庞大的情况下也可以作为侧面一种统计的依据。作为一个“有系统洁癖”的人果断是需要将此服务器关闭的。

一开始在服务中一直都没有找到这个叫做Network Connectivity Status Indicator (NCSI)服务，结果发现这家伙是直接写在注册表的服务项里的（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc），并没有显式表现出来，这让人不得不怀疑这服务是否本意就含有收集客户端信息来进行统计。需要关闭修改注册表键值HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NlaSvc\Parameters\Internet\下的EnableAcetiveProbing值为0即可，如图。

懒人可以直接下载下面的reg文件导入

[sfile][/sfile]

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

阅读全文>>

FreeBSD8.0+Nginx+FastCG+Mysql5.0的环境，本来跑Dedecms+Discuz!+UChome一切运转良好，后来升级到Discuz X1.5，由于合并之后Discuz X 1.5中有某个单表超过1G，偶尔会出现论坛不能访问的情况。

经检查不能访问时Nginx状态良好，只是reading数和writing数飙升，php-cgi进程大量提示sbwait状态，mysql负载居高不下，在mysql中运行show proceslist;得到回显如下

阅读全文>>

母系统为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文件添加如下信息：
...

阅读全文>>

在Ubuntu10.04下默认使用NetworkManager，每次更换网络环境：如更换无线接入热点，更换所在局域网设置，更换拨号等等。NetworkManager都会有独立的一套设置保存着。这也就意味着每次重新连接网络resolv.conf文件就将被重写:无论之前的resolv.conf中是什么内容，都将被先清空然后在加上“# Generated by NetworkManager”字样和相应环境的nameserver设置。这本来没有多大问题，但是当我启用了dnsmasq来加速DNS解析，或者是我一直想用一个固定的DNS服务器，又或者是我的网络在NetworkManager中没有设置DNS服务器的时候就会遇到一些麻烦。

要禁止NetworkManager重置resolv.conf文件可以这样：

修改好相应的resolv.conf之后用

sudo chattr +i /etc/resolv.conf

命令将resolv.conf文件变成只读，这样NetworkManager就不能修改resolv.conf文件了。

（另外可以将sudo chattr +i /etc/resolv.conf加到/etc/rc.local里面的exit 0之前的任何位置）

阅读全文>>

阅读全文>>