核心層網路棧最佳化專案Fastsocket背後的故事
2014年10月18日,當時就職於新浪作業系統團隊的林曉峰在Github上開源了名為Fastsocket的專案,並在之後一天的中國Linux核心開發者大會上對該專案的原理和應用效果進行了介紹(演講slides在此)。根據Github官網的介紹,Fastsocket是:
- 高度可擴充套件的socket
- 是Linux核心層面的底層網路實現
- 在多核機器上可實現極佳效能,24核以內的效能增長呈線性,遠超過預設核心在12核以上的機器就會出現效能下降的情況
- 非常容易使用和維護,應用程式碼無需變更
- 針對kernel-2.6.32-431.17.1.el6/CentOS-6.5的實現
- 已經在新浪的生產環境部署
- 由新浪的作業系統團隊發起
- 清華大學作業系統實驗室、Intel、哲思自由軟體社群(Zeuux)對該專案均有支援
- 開源協議為GPLv2
開源之後的兩週之內,該專案迅速收穫了1800多個star和200多個fork,可以說成為了開源社群又一新的熱點專案。近日,InfoQ編輯對Fastsocket的主要維護人員林曉峰、新浪作業系統團隊的負責人李曉棟進行了郵件採訪,瞭解有關Fastsocket專案的更多背景。
InfoQ:簡單介紹一下fastsocket的開發背景吧。這個專案主要是你在新浪這邊跟清華大學的作業系統實驗室一起合作。一開始是在什麼時候發起的?發起的動機是什麼?與清華大學的作業系統實驗室、Intel和哲思自由軟體社群的合作模式是怎樣的?
李曉棟:要說明清楚這點,需要從我們在新浪內部發起的FastOS計劃談起。
從技術上講,FastOS 計劃要做的是對Linux核心“協議棧、檔案系統、IO”等不同子系統進行定向性的最佳化,以滿足高效能網站的實際需要。Fastsocket是FastOS計劃中的第一個子專案,今後我們還會推出FastTCP、FastIO……
從管理理念上講,FastOS期望打造的是一個有公司保障、但沒有公司邊界、開放式的生態系統,可參與該計劃的不僅有新浪,而且還包括:各類硬體提供商、高校實驗室、國內外自由軟體組織、IT媒體、網際網路技術同行以及對我們計劃感興趣的任何開發者。所有正式加入我們FastOS合作計劃的組織和個人,不僅可從共享通道中獲得各合作方提供的軟硬體及宣傳資源,更為重要的是: 在對其它合作方利益無損的前提下,可以各取所需,實現合作成果的最大化分享。前面提到FastOS計劃是有公司保障的,一是指該計劃中所有的子專案都是在新浪生產環境中被正式使用的,所有公開的測試資料都是真實的,有可信度方面的保障;二是指FastOS計劃的日常運作管理由新浪作業系統團隊做長期保障,有一套明確的治理細節和管理流程,同時我們會充分考慮並切實避免合作方之間的利益衝突。 在這裡,我們也誠邀請大家加入進來。
林曉峰:Fastsocket專案與2013年初正式立項,該專案最初要解決的問題就是要提升七層交換服務的Haproxy的單機效能。提升單機效能根本原因在於降低成本,包括硬體相關成本和叢集運維成本。經過Haproxy系統詳盡分析後,我們發現大部分CPU資源消耗在kernel裡,並且在多核平臺下,kernel在網路協議棧處理過程中存在著大量同步開銷。據此,我們將開發kernel並行網路協議棧作為核心目標,來滿足未來多核平臺下萬兆高效能的網路需求。隨著Fastsocket展現出強勁的效能優勢,以及在新浪生產環境落地,我們希望可以將專案成果整理過學術論文,並有信心衝擊國際頂級系統和網路方面的技術會議。藉助合作伙伴Intel的牽線,我們聯絡到了清華作業系統中心的陳渝教授,我們一拍即合的開始Fastsocket專案的深入合作,並且完成了Fastsocket論文,並已經向相關會議投稿,目前在等待結果。
InfoQ:如你之前的分享所說,多核機器在沒有最佳化之前,CPU資源大多消耗在鎖上面了。多執行緒的效能提升一般有哪些手段,各自的原理是什麼?
林曉峰:我並不是多執行緒程式設計專家,不過可以給一些有關多核平臺效能最佳化的通用建議。設計程式框架的時候,要儘可能的避免多執行緒訪問需要同步的共享資源,互斥上鎖是多核平臺效能第一殺手,每個執行緒只訪問自己的資料是多核平臺最高效,使用者程式和系統核心裡都一樣。另外,執行緒數量不宜太多,並最好和核心繫結,執行緒排程也是有開銷的,保持執行緒在一個核心上執行可以讓CPU cache更高效。
InfoQ:簡單介紹一下Fastsocket提升效能的技術原理?做了哪些技術上的實現或最佳化?
林曉峰:Fastsocket提升效能,主要在於提高了kernel網路協議棧的效率,所以網路I/O密集的應用可以收到很好的效能提升效果。Fastsocket對網路協議棧內部最佳化,在github上的主線有總計7個最佳化特性。這些最佳化可以分為兩個維度。
第一個維度是多核擴充套件性的最佳化,也就是讓kernel網路協議棧在多核平臺發揮多核的並行處理優勢。這個維度又可以分為兩個方向:一是,將網路協議棧處理的關鍵資料結構做CPU核心間的隔離,使得每個核心有完全本地的訪問資料,從而消除了執行路徑上核心間的同步開銷。二是,使得任意的某個TCP連線的全部處理,都在一個核心上完成,這樣可以最大化的提高CPU cache利用率。
第二個維度是單核效能的提升,也就是不考慮多核同步的情況下,如何提升網路協議棧在單個核心上的絕對效能。這個維度也可以分為兩個方向:一是,將kernel中的通用服務為網路I/O做專用定製,來提升網路協議棧的效能。二是,做網路協議棧的跨層最佳化,改變傳統協議棧TCP/IP協議棧的嚴格分層處理,將傳輸的關鍵資訊垂直貫穿網路協議棧,來做全域性的最佳化。
InfoQ:Nginx在CPU均衡上已很不錯了,factsocket對於吞吐量的增加是如何實現的?後續是否考慮做成nginx modules?針對HAProxy的實現與Nginx一樣嗎?有什麼差異?
林曉峰:Fastsocket是核心層面的最佳化,對使用者程式是透明的,並不需要開發Nginx模組來支援。Fastsocket對應用程式來說通用的,提升的是核心網路協議棧的效率。
InfoQ:吞吐量的提升通用於4、7層代理嗎?
林曉峰:Fastsocket對於網路效能的提升,適用於使用socket API來進行網路I/O的應用程式,所以我們將它命名為Fastsocket。如果4層代理是指LVS,那是Fastsocket是不適用的,因為LVS功能是藉助kernel裡Netfilter框架實現的。
InfoQ:像Fastsocket這類以效能最佳化為主打的開源專案,品質保障、技術方案選擇、成本管控非常重要,你能介紹一下這方面的經驗嗎?
李曉棟:在做效能最佳化的過程中,很多時候我們往往會陷入到僅關注效能指標的誤區,而忽視了程式交付給運維人員後的部署成本、運維成本。比方說:是否跟現有的上層軟體、運維手段相容?有無自動化的部署指令碼?應急回滾是否方便?是否提供了良好的統計和追蹤機制?等等等等。這些都需要在方案設計環節充分考慮,否則很有可能出現“運維成本” 大於“效能提升所節省的硬體成本”,最終導致無法在生產環境中很好地使用起來。也就是說,我們需要在效能和可運維之間找到一個最佳平衡點。其實在Fastsocket之前我們還有一版內部代號為“Hydra”的預覽版,效能比現在的Fastsocket要更好,但需要修改haproxy、nginx等上層軟體的程式碼,運維成本過高,因此被我們果斷放棄了。關於品質保障,我覺得最好的辦法就是,在設計測試用例時,要把生產環境中可能出現的各類正常、非正常操作和情景儘量都考慮進去,最好能讓比較資深的運維人員參與到測試用例設計中。當然,測試過程中,細心必不可少,要能敏銳捕捉異常情況。
InfoQ:Fastsocket開源之後立刻在Github上得到了上千個star,看來很多人也有這方面的需求。目前主要得到的反饋有哪些?
林曉峰:Fastsocket在Github上正式開源到現在剛兩週多,到寫稿時已經接近兩千star,這是出乎我們意料的。
我們收到的反饋主要分為兩方面。一是,具體是如何實現的,對其效能的大幅效能的技術點很有興趣。二是,比較關注Fastsocket是否有移植到3.X kernel版本和合併到kernel主線的計劃。在Haproxy的mailing list上也看到關於Fastsocket的討論,很高興的看到Haproxy作者對我們專案也很感興趣,並表示可以考慮對Fastsocket進行直接支援。
InfoQ:有其他公司的人來參與支援這個嗎?未來以開源模式更新,對於專案的commit、review機制有什麼計劃?
林曉峰:據我個人所知,已經幾家大型網際網路公司對Fastsocket有試用的興趣。目前專案的commit主要採用Github的pull request機制,由我來review程式碼。未來希望可以吸納更多活躍的開發者作為committer,用社群方式去維護Fastsocket專案。
InfoQ:Fastsocket後續對新版本的核心、新版本的CentOS的支援,計劃用怎樣的方式去長期維持?
李曉棟:Fastsocket對不同版本核心和CentOS發行版的持續支援,採用兩種方式:一是由新浪根據生產環境需要和作業系統使用策略,適時升級,這種方式相對比較穩健和持續,但更新週期相對要長一些。第二種方式是依託社群的支援,目前已有熱心貢獻者願意幫助我們將fastsocket移植到CentOS7下,在這裡我們也表示深深感謝。
受訪者簡介
林曉峰,前新浪網高階系統開發工程師,關注網路,關注高效能,關注Linux核心。
李曉棟,新浪網研發中心高階技術經理,有十年的網際網路工作經驗,是“新浪軟體負載均衡系統” 和“ 新浪作業系統管理與最佳化”方面的重要開拓者,也是FastOS計劃和管理理念的提出者。
相關文章
- 谷歌氣球上網專案背後的故事谷歌
- TCP/IP協議之網路連結的背後故事TCP協議
- 10個社交網站背後的故事網站
- 全棧技能與平衡藝術:首枚面向物聯網AI晶片UniOne背後的故事全棧AI晶片
- Redis持久化背後的故事Redis持久化
- Java main方法背後的故事?JavaAI
- Mac OS X 背後的故事Mac
- HTML5背後的故事HTML
- 網際網路廣告背後是什麼(2):核心問題
- 專利背後的故事 | 一種郵件安全控制方法
- dyld背後的故事&原始碼分析原始碼
- 蘋果自動駕駛背後的故事蘋果自動駕駛
- 愛回收IPO背後的新老故事
- GCC編譯器背後的故事GC編譯
- RestCloud ETL 社群版背後的故事RESTCloud
- 微博春晚背後的技術故事
- 誰來背鍋?自動駕駛車禍背後的故事自動駕駛
- 袋鼠雲出品!數棧UI 5.0全新體驗升級,設計背後的故事UI
- 開源夜聊欄目開播:聊聊新晉 CNCF 專案 sealer 背後的故事
- 三層網路結構(核心層、匯聚層 、接入層)
- “網路實名制”的背後薦
- 郭超:阿里雲Cassandra背後的故事阿里
- 嵌入式—編譯器背後的故事編譯
- AI Gossip - 人工智慧背後的小故事AIGo人工智慧
- 重磅釋出背後:POLARDB的中國故事
- SSH 協議埠號 22 背後的故事協議
- 微軟開源 .Net 平臺的背後故事微軟
- 和 .project 檔案說“再見”—— VS Code Java 1.1.0 背後的故事ProjectJava
- Spring Cloud Alibaba 開源背後的故事 | 開源中國專訪SpringCloud
- 我和《獨角獸專案:數字化轉型時代的開發傳奇》背後的故事
- 騰訊與Github的魔幻會面背後的故事…Github
- 更好的 java 重試框架 sisyphus 背後的故事Java框架
- 網際網路公司背後的“大老闆”——資訊圖
- 網際網路金融:噪音背後的簡單真相
- 電商背後的網際網路金融大練兵
- 【前端軼事】Chrome 小恐龍背後的故事前端Chrome
- 請求 www.baidu.com 背後的故事AI
- 編譯器背後的故事(入門練習)編譯