月度归档:2010年10月

兔窝恢复访问

    半个月了,从要开两会开始,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的,正常了。

分布式系统带来的新的的技术难点和需要注意的地方真的很多,考虑的地方多很多。

妖气加油!

nfs优化(转)

转自: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

21:05,Z77,11车8号中铺

今天所有北京西到信阳的火车票都无票,连无座都没有。在我放弃回去的时候,广播里传出让我不能相信的声音,Z77信阳汉口方向有卧铺!!!想都不敢想的,比动车还抢手的Z77竟然预留有票,呵呵,太巧了。

买之,在10号候车厅旁边的麦当劳买了点东西吃,用了麦当劳的半小时免费Wifi上了会网,顺便给3G上网卡充值了,以免夜晚停机了没法监控服务器。

现在,火车就要开了,方明,丹丹,明天见!

X君,不好意思了,你三天后回北京见不到我了,嘿嘿。

希望今晚服务器正常。

国庆,我依旧在公司。

今天观察一天Cacti的监控和网站运行情况了,到现在,没有任何异常,今天应该不会有什么问题了。

唉,前天的一场现在还没有最终结论,继续观察吧,纠结的新版本。

ps:中国航天,加油!Happy birthday,China!

CZ-3C,好样的,嫦娥二号加油,期待CZ-5、CZ-6研制顺利,2014年,我们拭目以待。

阿丽亚娜,质子,你们颤抖了吗?

US的土星,中国赶上来了!