后来又测试了几次，等到新申请的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了。在调整内核参数里有讲，怎么修改内核参数提高服务器抗秒杀能力，但是不能杜绝。
下图为2007年一场比赛时,单机25w+ connections，2.86w req/s,的状态(2CPU*2Core 1.86GHZ):
奥运结束后，我对服务器程序和架构做了调整，砍掉了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% 。
下图为30w+ connections, 4.6w req/s 的时候我的程序使用的资源情况(2cpu*4Core):
下图为cpu使用分布情况,cpu0空闲率只剩 6% (2cpu*4Core):
另外附上一个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";我算了一笔帐，行情好的时候每秒会产生30~40w个请求，一般一个请求会请求3~50只股票，保守点就按每个请求5只股票来计算，每秒会产生200w只股票查询信息。 由于这7个字节产生的带宽为： 200w * 7byte * 8bit / 1024 /1024 = 106.8 M ,而往往我们的带宽要按峰值来准备，按1G带宽100w RMB/year 计算，每年耗费10.68w RMB。把这笔钱拿给我做奖金，我会很happy的 ^-^ . 现在因为很多页面都使用了行情数据，想修改，代价很高。
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";
所以设计系统的时候一定要考虑的稍微远一些,哪怕当时只是一点点微不足道的地方，要考虑将来访问规模变大了会是什么后果。还有就是要敢于坚持自己的原则。
