楊建：網站加速--服務器編寫篇 (下)(2008-12-08 20:08:42)
--提升性能的同時爲你節約10倍以上成本
From: http://blog.sina.com.cn/iyangjian
七，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了。在調整內核參數裏有講，怎麼修改內核參數提高服務器抗秒殺能力，但是不能杜絕。
下圖爲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
所以設計系統的時候一定要考慮的稍微遠一些,哪怕當時只是一點點微不足道的地方，要考慮將來訪問規模變大了會是什麼後果。還有就是要敢於堅持自己的原則
From: http://blog.sina.com.cn/iyangjian
七，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了。在調整內核參數裏有講，怎麼修改內核參數提高服務器抗秒殺能力，但是不能杜絕。
下圖爲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";
所以設計系統的時候一定要考慮的稍微遠一些,哪怕當時只是一點點微不足道的地方，要考慮將來訪問規模變大了會是什麼後果。還有就是要敢於堅持自己的原則