月度归档:2010年09月

让人郁闷的XEN

今天下午,和X君对XEN和实体机的网络表现差异在生产环境进行了测试,通过测试,基本可以证明昨天莫名的网络问题,是虚拟机网络IO的瓶颈造成的,现在没有确定的是到底因为虚拟网卡的参数问题还是XEN本身的虚拟硬件的技术瓶颈。

根据我们的测试数据,一台实体机上开两个XEN虚拟机,只要有一个网络吞吐量到60Mbps,这台虚拟机就会发生掉ping,内外网ping延时增加,丢包率上升。

相对应的,实体机,网络吞吐量外网达到95Mbps,同时内网达到92Mbps,如此巨大的流量对内网ping的影响也就是从0.08x ms增加到0.10x ms,外网从49ms增加到51ms,基本无压力。

而且同一台实体机上的两个虚拟机在有一台网络高负荷的时候会对两外一台同宿主机的虚拟机产生轻微的影响。

这些都不是我们希望看到的,虽然我们有足够的前端,我们有足够的带宽,我们也丝毫不怀疑nginx的负载能力,但是还是早点上CDN比较稳妥,前端迟早都要换回实体机,要不然,以后肯定是隐患和瓶颈。

PS:今天发现了一个有趣的现象:在一台XEN虚拟机A上从一台实体机B上拷东西的同时用另一台实体机C来ping A,用cp和scp会有完全不同的结果。

用cp通过nfs拷,C ping A的延时从0.9ms立刻上升到3ms,并且飘忽不定。

用scp拷,C ping A完全无影响,一直都是0.9ms。

但是cp和scp用时几乎一样,平均速度都差不多。

真是很神奇,难道cp拷东西的同时会发送大量的ICMP或者UDP数据包?

一点都休息不得,杯具啊

终于,经过前天夜晚通宵到昨天早上7点的加班,服务器成功迁移到SDO机房了,几台和二三十台的集群差距还是很明显的。

昨天一切正常,本以为可以放松放松的时候,下午又囧了。从测试CDN把图片切回源站后,前端启用太少,开始顶不住了。立刻修改net内核参数,略有改善,但是延时依旧很大。面对如此巨大的流量,如果是原来的机房还真的扛不住,只好启用多台前端,还好SDO不差钱,不差带宽,启用多台前端后均衡下来了。

忙到刚才,明天才是真正的高峰,明晚继续战斗!

希望中秋前能切回正式的CDN,要不然,总让机房顶着几百M的流量确实有点不好意思。而且要到中秋和十一长假了,我们的用户群要放假了,有充足时间上网了,那时候压力才会真真正正上来,拭目以待!

妖气加油!

Cacti不生成rra的一个关键原因–权限

部署集群的时候,Cacti监控是必须要的。很多cacti用户在配置的时候会不生成rra导致无图。其实,只要注意权限问题就可以轻松解决这个问题。

重点就是:定时执行poller.php的crond的用户必须是cacti用户。不要手动用vi去修改crond的配置。应该在root用户下su到cacti用户执行crontab -e,修改完毕后su回root就可以了。可以顺利的生成rra,图也正常生成了。根本不用去chown那个rra的文件夹。