当前位置: 首页 > 网站架构 > 正文

网站加速–服务器编写篇 (下)

关键字:
1 星2 星3 星4 星5 星 (暂无评分)
Loading ... Loading ...
baidu_share
七,NBA js直播的发展历程

这一节就谈下这个项目发展过程中所遇到的瓶颈,以及如何解决的。
应该是06年吧,当时NBA 比赛比较火,woocall负责高速模式图文直播放,普通模式和动态比分数据等都放在一群破服务器上,大概有十几20台,这些破服务器有些扛不住了。

因为第二天有一场比较大的比赛,我想埋连接在线上测一下效果,于是连夜把财经实时行情server改写成了NBA JS直播server. 当时有两台 Intel(R) Xeon(TM) CPU 3.00GHz 双cpu的服务器,在F5后面。先启用一台服务器,比赛开始前静悄悄的,不一会,迅速串到了20w connections,再往上增长,就慢的几乎不可访问, ethtool eth0 , Speed: 100Mb/s, 网卡出口带宽跑满了(那时候支持千兆的交换机还不多)。迅速把另一台服务器启用,后来又卡了,好象是F5处理能力不足。 后来升级服务器出口带宽为1G,当然这需要交换机支持千兆口,更换网线,服务器也从F5后面转移出来,通过DNS直接轮询。

后来又测试了几次,等到新申请的Intel(R) Xeon(R) CPU 5120 @ 1.86GHz, 双核双cpu服务器一到,就开始大规模部署,比赛更火了,不巧的是行情也火了起来,我的财经实时图片系统和行情系统也是带宽杀手,同时我也成了服务器杀 手,到处蹭服务器。IDC带宽出口开始告急,我每天开始关注哪个机房还有富余带宽,有的机房被我们跑的太满,开始有人劝我们迁移到别的机房。后来 yangguang4劝我支持gzip输出,我觉得动态压缩太耗费cpu,不知道预先压缩是否可行,写个程序试了一把,没问题,于是NBA JS直播的的带宽一下子被砍掉了70%,而且没浪费一点我们的cpu,赚大了。

之后的两年里NBA JS服务一直很稳定,我几乎都没怎么看过,2007年的一场体育赛事中,单机达到25w+ connections,2.86w req/s ,cpu空闲30% ,见下图 (2CPU*2Core 1.86GHZ服务器) 。直到奥运期间,有场赛事,woocall瞬间仍给我近200w connections,网通的服务器被秒杀了1/3。 这其实就是善意的DDOS攻击,这些用户如果正常进入是没有问题了,瞬间扔过来,超出了操作系统极限,系统挂掉了,我的服务也over了。在调整内核参数里有讲,怎么修改内核参数提高服务器抗秒杀能力,但是不能杜绝。

奥运结束后,我对服务器程序和架构做了调整,砍掉了2/3的服务器。 但我没留意的是,同样connections,实际http请求增加了一倍,因为新上了一个flash方位图,里面增加了3个js,增加就增加吧,既然砍了就不准备再恢复了。但是服务在2CPU*4Core centos5 32bit上的表现却让我很失望,跑不过2CPU*2Core centos4 32bit 。 我开始怀疑程序升级的时候是不是有什么地方没考虑到,开始调程序,折腾几天没有结果,症状是单机支撑12.5万时候没有任何异常,内存使用1%左右,总cpu使用了5%左右,load 0.5,但是再增加0.1w用户server肯定崩溃,每次都是相同的表现,我知道在什么地方卡住了。 后来看了下dmesg,才恍然大悟,我是被32bit centos 5的内核暗杀的(Out of memory: Killed process xxx)。

32位机上LowFree一般是会变化的(cat /proc/meminfo | grep LowFree),最大不能超过880M(这个值不能改变除非用hugemem内核),在centos4 上有内核参数vm.lower_zone_protection(单位是M)来调节LowFree,默认vm.lower_zone_protection=0 ,LowFree=16M,但是在centos5上这个参数貌似被取消了,改变不了。 从使用经验来看,也就是你能申请16M~880M这么大的连续内存,但是16M以上不保证你能申请的到。centos4用到64M以上都没什么问题,centos5 用40M+ 就被OOM Killer给毙了。

本周开始使用64bit centos5.2进行测试,迁移很顺利,没有修改一行代码,他们把整个16G物理内存都作为LowFree,这下可以随便挥霍了(尽管如此我还是会节约的),前几天的比赛,这个64bit机跑了18w connections,很安静,未见异常,等有大比赛再检验下,没问题的话就开始大规模使用64bit系统。

目前看来,如果成功迁移64bit系统似乎可以高枕无忧了,但是我还是有两个忧虑:

1,再突然甩200w connections给我,我不敢保证能扛的住,因为现在服务器数量消减太多,需要yangguang4那边做策略调整,在比赛结束后,平滑的把用户丢给我,这应该有个持续过程,而不是一秒内的瞬间。

2,我猜这个系统,单机支撑到30w conections的时候会遇到瓶颈,因为网卡的中断集中在cpu0上,没有均衡开。我们有硬件解决方案已经实现(每个服务器会多2000RMB开销)我只部署了一台,但是软的还没实现,寄希望于xiaodong2 。

补充:
昨天的比赛中,一台64bit机,单机支撑30w+ connections,cpu0空闲率只剩6%,和我的预料是一致的。当时的CPU总量被我用掉近 1/4,内存被我用掉 0.5% 。

另外附上一个23w connections, 3.5w req/s 的时候我的程序使用的资源情况(2cpu*4Core),当时cpu只被用掉1/8,内存被用掉 0.4% ,cpu没有发挥线性增加的作用,我肯定不说能我可以支撑23w*8,但是保守地说,只要把网卡中断分散一下,单机50w+ connections很easy。

八,新浪财经实时行情系统的历史遗留问题 (7 byte = 10.68w RMB/year)

这点我还是提下吧,估计我不说,大家也想不到。
先感谢wangyun同学的大胆使用才有了今天的财经实时行情系统(当初是从一台PIII 900服务器上发展起来的,前几天刚被我下线)不过 “hq_str_” 这7个字节的前缀,也是他造成的,当初他说改抓取页面有些麻烦,就让我写死在server里,虽然意识到将来也许会有隐患,但我还是照做了。见下面返回数据:

http://hq.sinajs.cn/list=s_sz000609,s_sz000723,s_sh000001
var hq_str_s_sz000609="绵世股份,9.29,-0.05,-0.54,170945,16418"; 
var hq_str_s_sz000723="美锦能源,0.00,0.00,0.00,0,0"; 
var hq_str_s_sh000001="上证指数,2031.681,-47.436,-2.28,1216967,8777380";

我算了一笔帐,行情好的时候每秒会产生30~40w个请求,一般一个请求会请求3~50只股票,保守点就按每个请求5只股票来计算,每秒会产生200w只股票查询信息。 由于这7个字节产生的带宽为: 200w * 7byte * 8bit / 1024 /1024 = 106.8 M ,而往往我们的带宽要按峰值来准备,按1G带宽100w RMB/year 计算,每年耗费10.68w RMB。把这笔钱拿给我做奖金,我会很happy的 ^-^ . 现在因为很多页面都使用了行情数据,想修改,代价很高。

所以设计系统的时候一定要考虑的稍微远一些,哪怕当时只是一点点微不足道的地方,要考虑将来访问规模变大了会是什么后果。还有就是要敢于坚持自己的原则。

本文固定链接: http://www.chepoo.com/site-accelerator-server-2.html | IT技术精华网

网站加速–服务器编写篇 (下):等您坐沙发呢!

发表评论