楊建：網(wǎng)站加速--服務(wù)器編寫篇 (下)

wingate99 2009-05-10

展開全文

--提升性能的同時為你節(jié)約10倍以上成本
From: http://blog.sina.com.cn/iyangjian

七，NBA js直播的發(fā)展歷程

這一節(jié)就談下這個項目發(fā)展過程中所遇到的瓶頸，以及如何解決的。
應(yīng)該是06年吧，當時NBA 比賽比較火,woocall負責高速模式圖文直播放，普通模式和動態(tài)比分數(shù)據(jù)等都放在一群破服務(wù)器上，大概有十幾20臺，這些破服務(wù)器有些扛不住了。

因為第二天有一場比較大的比賽，我想埋連接在線上測一下效果，于是連夜把財經(jīng)實時行情server改寫成了NBA JS直播server. 當時有兩臺 Intel(R) Xeon(TM) CPU 3.00GHz 雙cpu的服務(wù)器，在F5后面。先啟用一臺服務(wù)器，比賽開始前靜悄悄的，不一會，迅速串到了20w connections，再往上增長，就慢的幾乎不可訪問， ethtool eth0 , Speed: 100Mb/s, 網(wǎng)卡出口帶寬跑滿了（那時候支持千兆的交換機還不多）。迅速把另一臺服務(wù)器啟用，后來又卡了，好象是F5處理能力不足。后來升級服務(wù)器出口帶寬為1G，當然這需要交換機支持千兆口，更換網(wǎng)線，服務(wù)器也從F5后面轉(zhuǎn)移出來，通過DNS直接輪詢。

后來又測試了幾次，等到新申請的Intel(R) Xeon(R) CPU 5120 @ 1.86GHz，雙核雙cpu服務(wù)器一到，就開始大規(guī)模部署，比賽更火了，不巧的是行情也火了起來，我的財經(jīng)實時圖片系統(tǒng)和行情系統(tǒng)也是帶寬殺手，同時我也成了服務(wù)器殺手，到處蹭服務(wù)器。IDC帶寬出口開始告急,我每天開始關(guān)注哪個機房還有富余帶寬，有的機房被我們跑的太滿，開始有人勸我們遷移到別的機房。后來 yangguang4勸我支持gzip輸出，我覺得動態(tài)壓縮太耗費cpu，不知道預(yù)先壓縮是否可行，寫個程序試了一把，沒問題，于是NBA JS直播的的帶寬一下子被砍掉了70%,而且沒浪費一點我們的cpu，賺大了。

之后的兩年里NBA JS服務(wù)一直很穩(wěn)定，我?guī)缀醵紱]怎么看過，2007年的一場體育賽事中，單機達到25w+ connections，2.86w req/s ,cpu空閑30% ,見下圖 (2CPU*2Core 1.86GHZ服務(wù)器) 。直到奧運期間，有場賽事，woocall瞬間仍給我近200w connections，網(wǎng)通的服務(wù)器被秒殺了1/3。這其實就是善意的DDOS攻擊,這些用戶如果正常進入是沒有問題了，瞬間扔過來，超出了操作系統(tǒng)極限，系統(tǒng)掛掉了，我的服務(wù)也over了。在調(diào)整內(nèi)核參數(shù)里有講，怎么修改內(nèi)核參數(shù)提高服務(wù)器抗秒殺能力，但是不能杜絕。

下圖為2007年一場比賽時,單機25w+ connections，2.86w req/s,的狀態(tài)(2CPU*2Core 1.86GHZ):

奧運結(jié)束后，我對服務(wù)器程序和架構(gòu)做了調(diào)整，砍掉了2/3的服務(wù)器。但我沒留意的是，同樣connections，實際http請求增加了一倍，因為新上了一個flash方位圖，里面增加了3個js，增加就增加吧，既然砍了就不準備再恢復(fù)了。但是服務(wù)在2CPU*4Core centos5 32bit上的表現(xiàn)卻讓我很失望，跑不過2CPU*2Core centos4 32bit 。我開始懷疑程序升級的時候是不是有什么地方?jīng)]考慮到，開始調(diào)程序，折騰幾天沒有結(jié)果，癥狀是單機支撐12.5萬時候沒有任何異常，內(nèi)存使用1%左右，總cpu使用了5%左右，load 0.5，但是再增加0.1w用戶server肯定崩潰，每次都是相同的表現(xiàn),我知道在什么地方卡住了。后來看了下dmesg，才恍然大悟，我是被32bit centos 5的內(nèi)核暗殺的(Out of memory: Killed process xxx)。

32位機上LowFree一般是會變化的(cat /proc/meminfo | grep LowFree)，最大不能超過880M（這個值不能改變除非用hugemem內(nèi)核)，在centos4 上有內(nèi)核參數(shù)vm.lower_zone_protection(單位是M)來調(diào)節(jié)LowFree，默認vm.lower_zone_protection=0 ，LowFree=16M，但是在centos5上這個參數(shù)貌似被取消了，改變不了。從使用經(jīng)驗來看，也就是你能申請16M~880M這么大的連續(xù)內(nèi)存，但是16M以上不保證你能申請的到。centos4用到64M以上都沒什么問題，centos5 用40M+ 就被OOM Killer給斃了。

本周開始使用64bit centos5.2進行測試，遷移很順利，沒有修改一行代碼，他們把整個16G物理內(nèi)存都作為LowFree，這下可以隨便揮霍了(盡管如此我還是會節(jié)約的)，前幾天的比賽，這個64bit機跑了18w connections，很安靜，未見異常，等有大比賽再檢驗下，沒問題的話就開始大規(guī)模使用64bit系統(tǒng)。

目前看來，如果成功遷移64bit系統(tǒng)似乎可以高枕無憂了，但是我還是有兩個憂慮:

1,再突然甩200w connections給我，我不敢保證能扛的住，因為現(xiàn)在服務(wù)器數(shù)量消減太多，需要yangguang4那邊做策略調(diào)整，在比賽結(jié)束后，平滑的把用戶丟給我,這應(yīng)該有個持續(xù)過程，而不是一秒內(nèi)的瞬間。

2,我猜這個系統(tǒng)，單機支撐到30w conections的時候會遇到瓶頸，因為網(wǎng)卡的中斷集中在cpu0上，沒有均衡開。我們有硬件解決方案已經(jīng)實現(xiàn)（每個服務(wù)器會多2000RMB開銷）我只部署了一臺，但是軟的還沒實現(xiàn),寄希望于xiaodong2 。

補充：
昨天的比賽中，一臺64bit機，單機支撐30w+ connections，cpu0空閑率只剩6%，和我的預(yù)料是一致的。當時的CPU總量被我用掉近 1/4，內(nèi)存被我用掉 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，內(nèi)存被用掉 0.4% ，cpu沒有發(fā)揮線性增加的作用,我肯定不說能我可以支撐23w*8,但是保守地說，只要把網(wǎng)卡中斷分散一下，單機50w+ connections很easy。

八，新浪財經(jīng)實時行情系統(tǒng)的歷史遺留問題 (7 byte = 10.68w RMB/year)

這點我還是提下吧，估計我不說，大家也想不到。
先感謝wangyun同學的大膽使用才有了今天的財經(jīng)實時行情系統(tǒng)（當初是從一臺PIII 900服務(wù)器上發(fā)展起來的，前幾天剛被我下線）不過 "hq_str_" 這7個字節(jié)的前綴，也是他造成的,當初他說改抓取頁面有些麻煩，就讓我寫死在server里，雖然意識到將來也許會有隱患，但我還是照做了。見下面返回數(shù)據(jù)：
http://hq./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="上證指數(shù),2031.681,-47.436,-2.28,1216967,8777380";

我算了一筆帳，行情好的時候每秒會產(chǎn)生30~40w個請求，一般一個請求會請求3~50只股票，保守點就按每個請求5只股票來計算，每秒會產(chǎn)生200w只股票查詢信息。由于這7個字節(jié)產(chǎn)生的帶寬為： 200w * 7byte * 8bit / 1024 /1024 = 106.8 M ,而往往我們的帶寬要按峰值來準備，按1G帶寬100w RMB/year 計算，每年耗費10.68w RMB。把這筆錢拿給我做獎金，我會很happy的 ^-^ . 現(xiàn)在因為很多頁面都使用了行情數(shù)據(jù)，想修改，代價很高。

所以設(shè)計系統(tǒng)的時候一定要考慮的稍微遠一些,哪怕當時只是一點點微不足道的地方，要考慮將來訪問規(guī)模變大了會是什么后果。還有就是要敢于堅持自己的原則。