半个月了，从要开两会开始，GAE依赖的ghs.google.com就被伟大的GFW给强奸了。兔窝的域名是cname到ghs.google.com来实现绑定的，于是，兔窝遭殃了，用GAE的童鞋们，同悲……
很忙，于是就没有解决这个问题，今天上网找资料的时候无意发现有个站提供类似ghs.google.com的cname中转，于是立刻登陆dnspod，修改cname到ghs.you8g.com.等了一会dns刷新好了，兔窝恢复访问。
不过兔窝的原始地址http://xusually.appspot.com一直可以访问的，就是不好记，还是名字的拼音好记一点。
转移域名到GoDaddy势在必行了啊，谁能给我多点时间，啊啊啊啊啊啊啊啊啊啊！忙！
撑不住了，写完日志就睡觉。
为庆祝妖气上线一周年，下午公司活动，集体去K歌，K了五个小时后聚餐，回到公司坐了一会就回来了，回来都十点多了。感觉好累啊，也不知道为啥。胳膊腿都酸酸的，难道是因为喝了啤酒的原因？貌似还真有点可能，喝了五瓶银子弹，呵呵，K房的酒真不便宜。
妖气加油，Kevin加油！
ps:明天还要早起，啵啵姐明天要去公司，我要给她开门去，我也得去公司收京东的货。
Good night to myself.
迁移到分布式集群后，困扰了我们很长时间的突发性Load异常终于在昨天找到原因了，原来是NFS的挂载选项引起的，我们之前挂载用的是sync模式，导致集群的web后端在往挂载于NFS服务器的日志目录打日志时会产生严重的延时，引起MySQL产生大量的sleep进程。而且在高并发的情况下，这种情况会不断的恶化，因为多个后端需要抢占日志文件，而sync决定了大家同时只能有一个后端在操作日志文件，其他的请求必须排队，高并发时nfsd的调度能力下降，会导致php-fpm出现大量的无法自己清理的sleep进程。
而且，由于我们自定义的日志是频繁打开和关闭文件的，于是，nfs用的portmap会产生大量的getattr类型的rpc call，查阅RedHat的文档的时候发现，频繁的getattr会大大降低nfs的性能，于是情况更加恶化了。所以前段时间妖气一直都不是很稳定。
经过在测试机上做的测试，把挂载选项调整为async后，往nfs上进行简单文件操作的php总执行时间从sync模式的25ms左右缩短到0.9ms，虽然和本机文件的0.0x ms比慢不少，但至少可以接受了。
async模式下，nfs服务端5s刷新一次脏数据到硬盘中，这个间隔还是可以接受的。调整为async后，日志都正常开启，MySQL的process list里面sleep终于没有了，偶尔有也是不超过1s的，正常了。
分布式系统带来的新的的技术难点和需要注意的地方真的很多，考虑的地方多很多。
妖气加油！
转自：http://www.linuxsky.org/doc/network/200709/130.html
1.设置块大小
mount命令的risize和wsize指定了server端和client端的传输的块大小。
mount -t nfs -o rsize=8192,wsize=8192,timeo=14,intr client:/partition /partition
如果未指定，系统根据nfs version来设置缺省的risize和wsize大小。大多数情况是4K对于nfs v2，最大是8K，对于v3，通过server端kernel设置risize和wsize的限制
vi /usr/src/linux2.4.22/include/linux/nfsd/const.h
修改常量: NFSSVC_MAXBLKSIZE
所有的2.4的的client都支持最大32K的传输块。系统缺省的块可能会太大或者太小，这主要取决于你的kernel和你的网卡，太大或者太小都有可能导致nfs速度很慢。
具体的可以使用Bonnie，Bonnie++，iozone等benchmark来测试不同risize和wsize下nfs的速度。当然，也可以使用dd来测试。
＃time dd if=/dev/zero of=/testfs/testfile bs=8k count=1024 测试nfs写
＃time dd if=/testfs/testfile of=/dev/null bs=8k 测试nfs读
测试时文件的大小至少是系统RAM的两倍，每次测试都使用umount 和mount对/testfs进行挂载，通过比较不同的块大小，得到优化的块大小。
2.网络传输包的大小
网络在包传输过程，对包要进行分组，过大或者过小都不能很好的利用网络的带宽，所以对网络要进行测试和调优。可以使用ping -s 2048 -f
hostname进行ping，尝试不同的package size，这样可以看到包的丢失情况。同时，可以使用nfsstat -o net
测试nfs使用udp传输时丢包的多少。因为统计不能清零，所以要先运行此命令记住该值，然后可以再次运行统计。如果，经过上面的统计丢包很多。那么可以
看看网络传输包的大小。使用下面的命令：
#tracepath node1/端口号
#ifconfig eth0
比较网卡的mtu和刚刚的pmtu，使用#ifconfig eth0 mtu
16436设置网卡的mtu和测试的一致。当然如果risize和wsize比mtu的值大，那么的话，server端的包传到client端就要进行重
组，这是要消耗client端的cpu资源。此外，包重组可能导致网络的不可信和丢包，任何的丢包都会是的rpc请求重新传输，rpc请求的重传有会导致
超时，严重降低nfs的性能。
可以通过查看
/proc/sys/net/ipv4/ipfrag_high_thresh
/proc/sys/net/ipv4/ipfrag_low_thresh
了解系统可以处理的包的数目，如果网络包到达了ipfrag_high_thresh，那么系统就会开始丢包，直到包的数目到达ipfrag_low_thresh。
3.nfs挂载的优化
timeo： 如果超时，客户端等待的时间，以十分之一秒计算
retrans： 超时尝试的次数。
bg： 后台挂载，很有用
hard： 如果server端没有响应，那么客户端一直尝试挂载
wsize： 写块大小
rsize： 读块大小
intr： 可以中断不成功的挂载
noatime： 不更新文件的inode访问时间，可以提高速度
async： 异步读写
4.nfsd的个数
缺省的系统在启动时，有8个nfsd进程
#ps -efl|grep nfsd
通过查看/proc/net/rpc/nfsd文件的th行，第一个是nfsd的个数，后十个是线程是用的时间数，第二个到第四个值如果很大，那么就需要增加nfsd的个数。
具体如下：
#vi /etc/init.d/nfs
找到RPCNFSDCOUNT,修改该值，一般和client端数目一致。
#service nfs restart
#mount -a
5.nfsd的队列长度
对于8个nfsd进程，系统的nfsd队列长度是64k大小，如果是多于8个，就要相应的增加相应的队列大小，具体的在
/proc/sys/net/core/rwmem_default
/proc/sys/net/core/wwmem_default
/proc/sys/net/core/rmmem_max
/proc/sys/net/core/wmmem_max
队列的长度最好是每一个nfsd有8k的大小。这样，server端就可以对client的请求作排队处理。如果要永久更改此值
#vi /etc/sysctl.conf
net.core.rmmem_default=数目
net.core.wmmem_default=数目
net.core.rmmem_max=数目
net.core.wmmem_max=数目
#service nfs restart
各种累
L602->CZ3175->ABC->Metro Line 10->Metro Line 1
今天所有北京西到信阳的火车票都无票，连无座都没有。在我放弃回去的时候，广播里传出让我不能相信的声音，Z77信阳汉口方向有卧铺！！！想都不敢想的，比动车还抢手的Z77竟然预留有票，呵呵，太巧了。
买之，在10号候车厅旁边的麦当劳买了点东西吃，用了麦当劳的半小时免费Wifi上了会网，顺便给3G上网卡充值了，以免夜晚停机了没法监控服务器。
现在，火车就要开了，方明，丹丹，明天见！
X君，不好意思了，你三天后回北京见不到我了，嘿嘿。
希望今晚服务器正常。
今天观察一天Cacti的监控和网站运行情况了，到现在，没有任何异常，今天应该不会有什么问题了。
唉，前天的一场现在还没有最终结论，继续观察吧，纠结的新版本。
ps:中国航天，加油！Happy birthday，China！
CZ-3C，好样的，嫦娥二号加油，期待CZ-5、CZ-6研制顺利，2014年，我们拭目以待。
阿丽亚娜，质子，你们颤抖了吗？
US的土星，中国赶上来了！