聶永的博客

前言

前面啰啰嗦嗦的幾篇文字，各個(gè)方面介紹了Fastsocket，盲人摸象一般，能力有限，還得繼續(xù)深入學(xué)習(xí)不是。這不，到了該小結(jié)收尾的時(shí)候了。

緣起，內(nèi)核已經(jīng)成為瓶頸

使用Linux作為服務(wù)器，在請求量很小的時(shí)候，是不用擔(dān)心其性能。但在海量的數(shù)據(jù)請求下，Linux內(nèi)核在TCP/IP網(wǎng)絡(luò)處理方面，已經(jīng)成為瓶頸。比如新浪在某臺(tái)HAProxy服務(wù)器上取樣，90%的CPU時(shí)間被內(nèi)核占用，應(yīng)用程序只能夠分配到較少的CPU時(shí)鐘周期的資源。

經(jīng)過Haproxy系統(tǒng)詳盡分析后，發(fā)現(xiàn)大部分CPU資源消耗在kernel里，并且在多核平臺(tái)下，kernel在網(wǎng)絡(luò)協(xié)議棧處理過程中存在著大量同步開銷。

同時(shí)在多核上進(jìn)行測試，HTTP CPS(Connection Per Second)吞吐量并沒有隨著CPU核數(shù)增加呈現(xiàn)線性增長：

內(nèi)核3.9之前的Linux TCP調(diào)用

• kernel 3.9之前的tcp socket實(shí)現(xiàn)
• bind系統(tǒng)調(diào)用會(huì)將socket和port進(jìn)行綁定，并加入全局tcp_hashinfo的bhash鏈表中
• 所有bind調(diào)用都會(huì)查詢這個(gè)bhash鏈表，如果port被占用，內(nèi)核會(huì)導(dǎo)致bind失敗
• listen則是根據(jù)用戶設(shè)置的隊(duì)列大小預(yù)先為tcp連接分配內(nèi)存空間
• 一個(gè)應(yīng)用在同一個(gè)port上只能listen一次，那么也就只有一個(gè)隊(duì)列來保存已經(jīng)建立的連接
• nginx在listen之后會(huì)fork處多個(gè)worker，每個(gè)worker會(huì)繼承l(wèi)isten的socket，每個(gè)worker會(huì)創(chuàng)建一個(gè)epoll fd，并將listen fd和accept的新連接的fd加入epoll fd
• 但是一旦新的連接到來，多個(gè)nginx worker只能排隊(duì)accept連接進(jìn)行處理
• 對(duì)于大量的短連接，accept顯然成為了一個(gè)瓶頸

Linux網(wǎng)絡(luò)堆棧所存在問題

• TCP處理&多核

  • 一個(gè)完整的TCP連接，中斷發(fā)生在一個(gè)CPU核上，但應(yīng)用數(shù)據(jù)處理可能會(huì)在另外一個(gè)核上
  • 不同CPU核心處理，帶來了鎖競爭和CPU Cache Miss（波動(dòng)不平衡）
  • 多個(gè)進(jìn)程監(jiān)聽一個(gè)TCP套接字，共享一個(gè)listen queue隊(duì)列
  • 用于連接管理全局哈希表格，存在資源競爭
  • epoll IO模型多進(jìn)程對(duì)accept等待，驚群現(xiàn)象
    
    

• Linux VFS的同步損耗嚴(yán)重

  • Socket被VFS管理
  • VFS對(duì)文件節(jié)點(diǎn)Inode和目錄Dentry有同步需求
  • SOCKET只需要在內(nèi)存中存在即可，非嚴(yán)格意義上文件系統(tǒng)，不需要Inode和Dentry
  • 代碼層面略過不必須的常規(guī)鎖，但又保持了足夠的兼容性

Fastsocket所作改進(jìn)

1. TCP單個(gè)連接完整處理做到了CPU本地化，避免了資源競爭
2. 保持完整BSD socket API

CPU之間不共享數(shù)據(jù)，并行化各自獨(dú)立處理TCP連接，也是其高效的主要原因。其架構(gòu)圖可以看出其改進(jìn)：

Fastsocket架構(gòu)圖可以很清晰說明其大致結(jié)構(gòu)，內(nèi)核態(tài)和用戶態(tài)通過ioctl函數(shù)傳輸。記得netmap在重寫網(wǎng)卡驅(qū)動(dòng)里面通過ioctl函數(shù)直接透傳到用戶態(tài)中，其更為高效，但沒有完整的TCP/IP網(wǎng)絡(luò)堆棧支持嘛。

Fastsocket的TCP調(diào)用圖

• 多個(gè)進(jìn)程可以同時(shí)listen在同一個(gè)port上
• 動(dòng)態(tài)鏈接庫libfsocket.so攔截socket、bind、listen等系統(tǒng)調(diào)用并進(jìn)入這個(gè)鏈接庫進(jìn)行處理
• 對(duì)于listen系統(tǒng)調(diào)用，fastsocket會(huì)記錄下這個(gè)fd，當(dāng)應(yīng)用通過epoll將這個(gè)fd加入到epoll fdset中時(shí)，libfsocket.so會(huì)通過ioctl為該進(jìn)程clone listen fd關(guān)聯(lián)的socket、sock、file的系統(tǒng)資源
• 內(nèi)核模塊將clone的socket再次調(diào)用bind和listen
• bind系統(tǒng)調(diào)用檢測到另外一個(gè)進(jìn)程綁定到已經(jīng)被綁定的port時(shí)，會(huì)進(jìn)行相關(guān)檢查
• 通過檢查sock將會(huì)被記錄到port相關(guān)聯(lián)的一個(gè)鏈表中，通過該鏈表可以知道所有bind同一個(gè)port的sock
• 而sock是關(guān)聯(lián)到fd的，進(jìn)程則持有fd，那么所有的資源就已經(jīng)關(guān)聯(lián)到一起
• 新的進(jìn)程再次調(diào)用listen系統(tǒng)調(diào)用的時(shí)候，fastsocket內(nèi)核會(huì)再次為其關(guān)聯(lián)的sock分配accept隊(duì)列
• 結(jié)果是多個(gè)進(jìn)程也就擁有了多個(gè)accept隊(duì)列，可避免cpu cache miss
• fastsocket提供將每個(gè)listen和accept的進(jìn)程綁定到用戶指定的CPU核
• 如果用戶未指定，fastsocket將會(huì)為該進(jìn)程默認(rèn)綁定一個(gè)空閑的CPU核

Fastsocket短連接性能

在新浪測試中，在24核的安裝有Centos 6.5的服務(wù)器上，借助于Fastsocket，Nginx和HAProxy每秒處理連接數(shù)指標(biāo)（connection/second）性能很驚人，分別增加290%和620%。這也證明了，F(xiàn)astsocket帶來了TCP連接快速處理的能力。 除此之外，借助于硬件特性：

• 借助于Intel超級(jí)線程，可以獲得另外20%的性能增長
• HAProxy代理服務(wù)器借助于網(wǎng)卡Flow-Director特性支持，吞吐量可增加15%

Fastsocket V1.0正式版從2014年3月份開始已經(jīng)在新浪生產(chǎn)環(huán)境中使用，用作代理服務(wù)器，因此大家可以考慮是否可以采用。針對(duì)1.0版本，以下環(huán)境較為收益：

• 服務(wù)器至少不少于8個(gè)CPU核心
• 短連接被大量使用
• CPU周期大部分消耗在網(wǎng)絡(luò)軟中斷和套接字系統(tǒng)調(diào)用上
• 應(yīng)用程序使用基于epoll的非阻塞IO
• 應(yīng)用程序使用多個(gè)進(jìn)程單獨(dú)接受連接

多線程嘛，就得需要參考示范應(yīng)用所提供實(shí)踐建議了。

Nginx測試服務(wù)器配置

• nginx工作進(jìn)程數(shù)量設(shè)置成CPU核數(shù)個(gè)
• http keep-alive特性被禁用
• 測試端http_load從nginx獲取64字節(jié)靜態(tài)文件，并發(fā)量為500*CPU核數(shù)
• 啟用內(nèi)存緩存靜態(tài)文件訪問，用于排除磁盤影響
• 務(wù)必禁用accept_mutex（多核訪問accept產(chǎn)生鎖競爭，另fastsocket內(nèi)核模塊為其去除了鎖競爭）

從下表測試圖片中，可以看到：

1. Fastsocket在24核服務(wù)器達(dá)到了475K Connection/Second，獲得了21倍的提升
2. Centos 6.5在CPU核數(shù)增長到12核時(shí)并沒有呈現(xiàn)線性增長勢頭，反而在24核時(shí)下降到159k CPS
3. Linux kernel 3.13在24核時(shí)獲得了近乎兩倍于Centos 6.5的吞吐量，283K CPS，但在12核后呈現(xiàn)出擴(kuò)展性瓶頸

HAProxy重要配置

• 工作進(jìn)程數(shù)量等同于CPU核數(shù)個(gè)
• 需要啟用RFD(Receive Flow Deliver)
• http keep-alive需要禁用
• 測試端http_load并發(fā)量為500*CPU核數(shù)
• 后端服務(wù)器響應(yīng)外圍64個(gè)字節(jié)的消息

測試結(jié)果中：

• fastsocket呈現(xiàn)出了驚人的擴(kuò)展性能
• 24核，Linux kernel 3.13成績?yōu)?39K CPS
• 24核，Centos 6.5借助Fastsocket，獲得了370K CPS的吞吐量

實(shí)際部署環(huán)境的成績

8核服務(wù)器線上環(huán)境運(yùn)行了24小時(shí)的成績，圖a展示了部署fastsocket之前CPU利用率，圖b為部署了fastsocekt之后的CPU利用率。 Fastsocket帶來的收益：

• 每個(gè)CPU核心負(fù)載均衡
• 平均CPU利用率降低10%
• HAProxy處理能力增長85%

其實(shí)吧，這一塊期待新浪公布更多的數(shù)據(jù)。

長連接的支持正在開發(fā)中

長連接支持，還是需要等一等的。但是要支持什么類型長連接？百萬級(jí)別應(yīng)用服務(wù)器類型，還是redis，可能是后者。雖然目前正做，但目前沒有時(shí)間表，但目前所做特性總結(jié)如下：

1. 網(wǎng)絡(luò)堆棧的定制
   • SKB-Pool，每一CPU核對(duì)應(yīng)一個(gè)預(yù)分配skb pool，替換內(nèi)核緩沖區(qū)kernel slab
     • Percore skb pool
     • 合并skb頭部和數(shù)據(jù)
     • 本地Pool和重復(fù)循環(huán)使用的Pool（Flow-Director）
   • Fast-Epoll
     • 多進(jìn)程之間TCP連接共享變得稀少
     • 在file結(jié)構(gòu)體中保存Epoll entry，用以節(jié)省調(diào)用epoll_ctl時(shí)紅黑樹查詢的開銷
2. 跨層的設(shè)計(jì)
   • Direct-TCP，數(shù)據(jù)包隸屬于已建立套接字會(huì)直接跳過路由過程
     • 記錄TCP套接字的輸入路由信息（Record input route information in TCP socket）
     • 直接查找網(wǎng)絡(luò)套接字在進(jìn)入網(wǎng)絡(luò)堆棧之前（Lookup socket directly before network stack）
     • 從套接字讀取輸入路由信息（Read input route information from socket）
     • 標(biāo)記數(shù)據(jù)包被路有過（Mark the packet as routed）
   • Receive-CPU-Selection 類似于RFS，但更輕巧、精準(zhǔn)與快速
     • 把當(dāng)前CPU核id編碼到套接字中（Application marks current CPU id in the socket）
     • 直接查詢套接字在進(jìn)入網(wǎng)絡(luò)堆棧之前（Lookup socket directly before network stack）
     • 讀取套接字中包含的CPU核，然后發(fā)送給它（Read CPU id from socket and deliver accordingly）
   • RPS-Framework 數(shù)據(jù)包在進(jìn)入網(wǎng)絡(luò)堆棧之前，讓開發(fā)者在內(nèi)核模塊之外定制數(shù)據(jù)包投遞規(guī)則，擴(kuò)充RPS功能

Redis測試結(jié)果

測試環(huán)境:

• CPU: Intel E5 2640 v2 (6 core) * 2
• NIC: Intel X520

Redis配置選項(xiàng):

• TCP持久連接
• 8個(gè)Redis實(shí)例，綁定不同端口
• 使用到8個(gè)CPU核心，并且綁定CPU核

測試結(jié)果：

• 僅開啟RSS：20%的吞吐量增加
• 啟用網(wǎng)卡Flow-Director特性：45%吞吐量增加

但需要注意：

• 僅為實(shí)驗(yàn)測試階段
• 為V1.0補(bǔ)充，Nginx和HAProxy同樣會(huì)收益

Fastsocket v1.1

V1.1版本要增加長連接的支持，那么類似于Redis的服務(wù)器應(yīng)用程序就很受益了，因?yàn)闆]有具體的時(shí)間表，只能夠慢慢等待了。

以后一些優(yōu)化措施

1. 在上下文切換時(shí)，避免拷貝操作，Zero-Copy
2. 中斷機(jī)制完善，減少中斷
3. 支持批量提交，降低系統(tǒng)函數(shù)調(diào)用
4. 提交到Linux kernel主分支上去
5. HugeTLB/HugePage等

Fastsocket和mTCP等簡單對(duì)比

說是對(duì)比，其實(shí)是我從mTCP論文中摘取出來，增加了Fastsocket一欄，可以看出人們一直努力的腳步。

有一個(gè)大致的印象，也方便對(duì)比，但這只能是一個(gè)暫時(shí)的摘要而已，人類對(duì)性能的渴求總是朝著更好的方向發(fā)展著。

部署嘗試

怎么說呢，F(xiàn)astsocket是為大家耳熟能詳服務(wù)器程序Nginx，HAProxy等而開發(fā)的。但若應(yīng)用環(huán)境為大量的短連接，并且是小文件類型請求，不需要強(qiáng)制支持Keep-alive特性（短連接要的是快速請求-相應(yīng)，然后關(guān)閉），那么管理員可以嘗試一下Fastsocket，至于部署策略，選擇性部署幾臺(tái)作為實(shí)驗(yàn)看看結(jié)果。

小結(jié)

本系列到此算是告一段落啦。以后呢，自然是希望Fastsocket盡快發(fā)布對(duì)長連接的支持，還有更高性能的提升咯 :))

資源引用

• fastsocket github
• fastsocket優(yōu)化網(wǎng)絡(luò)性能原理