作者归档:兔兔风

昨天加班到今天凌晨1:36,可恶的nginx!

nginx的缓存规则有了变化,或者说nginx对缓存部分做了bug fix,于是我们以前的写法就不生效了,研究了好久,终于搞定了。

这是继location的写法变化后另一个重大的变化,让我们好囧啊,现在的nginx,越来越向squid发展了,不喜欢。

ps:回去还淋雨了,好大的雨。

新项目又来咯……妖子们,期待吧

回到座位上,看着新邮件的提示,点开,trac系统自动发送的,雷哥切完页面了,我要开工啦。

加上不董君9页的需求文档,国庆前一天的Deadline。看来之前我预计的真没错,十一前是闲不下来了,杯具呀。

上了CDN后,服务器那边表现还算不错,服务器集群不出问题我就轻松多了,确实有段时间没有正儿八经写网站的程序了,恢复恢复手感,嘿嘿。

妖气加油,妖子赛高!

PS:昨天还是做了个挺有用的东西,Cacti的插件demo,用来通过监控机远程在集群的其他机器上执行命令的WebShell,只写了雏形,忙完这个项目就好好完善一下,X君对这个插件demo还是抱有很大期望的,当然,我自己也是。发个开发版截图,请无视一个从来不会用PS的人–我自己用CS5改的那个logo以及Shell上方输出的调试信息…..

终于上盛大的正式CDN了

中秋的前一天终于上了盛大正式的CDN,刚才切域名的时候手还抖了一下差点切错,这杯具的天气,嘿嘿嘿……

好啦,这下机房不用担心流量了,不用连夜跟电信联系改计费方案了,不用担心上联拥塞了,不用担心……

但是,XEN虚拟机网络效率比较低的问题还是要解决的。

还有我们的Nginx监控,还在悲催着,难道真的要哥自己写么?好吧,我承认,貌似除了这样,没有啥好的方案了。

让人郁闷的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的流量确实有点不好意思。而且要到中秋和十一长假了,我们的用户群要放假了,有充足时间上网了,那时候压力才会真真正正上来,拭目以待!

妖气加油!