高效能閘道器裝置及服務實踐(dpdk)--伺服器架構研究
針對海量的網路流量，轉發效能是我們最關鍵的一個方面，那構建高效能的後臺伺服器有哪些關鍵的技術和需要注意的地方，今天邀請了後臺開發同學童琳和鄭勝利來和大家一起談談。
一、引言
隨著網際網路的高速發展，內容量的提升以及對內容智慧的需求、雲產業的快速突起，作為網際網路的計算基石伺服器的形態以及使用成為了炙手可熱的話題，全球各家大型網際網路公司都持續的在伺服器平臺上有非常大的動作，譬如facebook的OCP等，而整個伺服器的生態鏈也得到了促進和發展。隨著伺服器硬體效能的提升和網路硬體的開放，傳統PC機的處理效能甚者可以和網路裝置相媲美。另一方面SDN技術的發展，基礎架構網路逐漸偏向基於通用計算平臺或模組化計算平臺的架構融合，來支援多樣化的網路功能，傳統的PC機器在分散式計算平臺上的優勢更為明顯。在這些針對海量資料處理或海量使用者的服務場景，高效能程式設計顯得尤為重要。
本文講述了從C10K到C10M過程中程式設計模式的改變；接著介紹了Intel DPDK開發套件如何突破作業系統限制，給開發高效能網路服務的程式設計師帶來的福音；之後總結高效能程式設計的一些其它的優化方法；最後分享我們利用DPDK技術來實現的高效能閘道器裝置和服務程式案例。
二、C10K到C10M
前10年中，網路程式效能優化的目標主要是為了解決C10K問題，其研究主要集中在如何管理數萬個客戶端併發連線，各種I/O框架下如何進行效能優化，以及作業系統引數的一些優化。
當前，解決C10K問題的伺服器已經非常多。Nginx和Lighttpd兩款非常優秀的基於事件驅動的web服務框架，Tornado和Django則是基於python開發的非阻塞的web框架；Yaws和Cowboy則是用Erlang開發輕量級web框架。這些軟體使得C10K已經不再是問題了。
今天，C10M成為新的研究主題了。也許你會感到奇怪，千萬級併發不是網路裝置的效能嗎？那是裝置廠商該做的事情吧，答案在以前是，但如今不是。在網際網路裝置廠商相對封閉軟體體系架構中，我們很少關注裝置內部的配置。但是當你去拆開一款交換機之後就會發現，裡面很可能就是我們PC機使用的x86晶片，即使不是x86，那也是標準的RISC處理器。也就是說現在的網際網路硬體裝置實際上很少是硬體組成——大部分都是軟體來實現的。所以千萬併發應該是我們軟體開發人員應該去研究的問題！騰訊自研的Bobcat就是一個基於x86平臺的自研裝置，效能可達千萬級別。
2.1非同步模式的弊端
我們知道，在解決C10K問題的時候，需要將軟體設計為非同步模式，使用epoll來高效的處理網路讀寫事件。但在面對C10M問題中，這樣設計是反而比較糟糕，為什麼這麼說呢？
一方面在基於多執行緒的伺服器設計框架中，在沒有請求到來的時候，執行緒將會休眠，當資料到來時，將由作業系統喚醒對應的執行緒，也就是說核心需要負責執行緒間頻繁的上下文切換，我們是在依靠作業系統排程系統來服務網路包的排程。
另一方面在以Ngnix為代表的伺服器場景，看上去僅使用一個執行緒監聽Epoll事件來避免上下文切換，但我們仍將繁重的事件通知工作交由作業系統來處理。
最後要說的是，網絡卡驅動收包本身也是一個非同步的過程，一般是當十幾個或者更多的資料包到達之後通過軟中斷例程一次性將資料包遞交到核心，而中斷效能本身就不高。相比老的suse核心，linux系統也只不過讓多佇列網絡卡把中斷分散在不同CPU核心上來提高收發包效能，要是能避免中斷就更好了。
在千萬級併發場景下，我們的目標是要回到最原始的方式，使用輪詢方式來完成一切操作，這樣才能提升效能。
2.2資料包的可擴充套件性
Unix誕生之初就是為電話電報控制而設計的，它的控制平面和資料轉發平面沒有分離，不適合處理大規模網路資料包。如果能讓應用程式直接接管網路資料包處理、記憶體管理以及CPU排程，那麼效能可以得到一個質的提升。
為了達到這個目標，第一個要解決的問題就是繞過Linux核心協議棧，因為Linux核心協議棧效能並不是很優秀，如果讓每一個數據包都經過Linux協議棧來處理，那將會非常的慢。像Wind River和6 Wind Gate等公司自研的核心協議棧宣稱比Linux UDP/TCP協議棧效能至少提高500%以上，因此能不用Linux協議棧就不用。
不用協議棧的話當然就需要自己寫驅動了，應用程式直接使用驅動的介面來收發報文。PF_RING，Netmap和intelDPDK等可以幫助你完成這些工作，並不需要我們自己去花費太多時間。
Intel官方測試文件給出了一個性能測試資料，在1S Sandbridge-EP 8*2.0GHz cores伺服器上進行效能測試，不用核心協議棧在使用者態下吞吐量可高達80Mpps（每個包處理消耗大約200 cpu clocks），相比之下，使用Linux核心協議棧效能連1Mpps都無法達到。
2.3多核的可擴充套件性
多核的可擴充套件性對效能提升也是非常重要的，因為伺服器中CPU頻率提升越來越慢，納米級工藝改進已經是非常困難的事情了，但可以做的是讓伺服器擁有更多的CPU和核心，像國家超級計算中心的天河二號使用了超過3w顆Xeon E5來提高效能。在程式設計過程中，即使在多核環境下也很快會碰到瓶頸，單純的增加了處理器個數並不能線性提升程式效能，反而會使整體效能越來越低。一是因為編寫程式碼的質量問題，沒有充分利用多核的並行性，二是伺服器軟體和硬體本身的一些特性成為新的瓶頸，像匯流排競爭、儲存體公用等諸多影響效能平行擴充套件的因素。
那麼，我們怎樣才能讓程式能在多個CPU核心上平行擴充套件：儘量讓每個核維護獨立資料結構；使用原子操作來避免衝突；使用無鎖資料結構避免執行緒間相互等待；設定CPU親緣性，將作業系統和應用程序繫結到特定的核心上，避免CPU資源競爭；在NUMA架構下儘量避免遠端記憶體訪問。當然自己來實現無鎖結構時要非常小心，避免出現ABA問題和不同CPU架構下的記憶體模型的差異。
2.4記憶體的可擴充套件性
記憶體的訪問速度永遠也趕不上cache和cpu的頻率，為了能讓效能平行擴充套件，最好是少訪問。
從記憶體消耗來看，如果每個使用者連線佔用2K的記憶體，10M個使用者將消耗20G記憶體，而作業系統的三級cache連20M都達不到，這麼多併發連線的情況下必然導致cache失效，從而頻繁的訪問記憶體來獲取資料。而一次記憶體訪問大約需要300 cpuclocks，這期間CPU幾乎被空閒。因此減少訪存次數來避免cachemisses是我們設計的目標。
指標不要隨意指向任意記憶體地址，因為這樣每一次指標的間接訪問可能會導致多次cache misses，最好將需要訪問的資料放到一起，方便一次性載入到cache中使用。
按照4K頁來計算，32G的資料需要佔用64M的頁表，使得頁表甚至無法放到cache中，這樣每次資料訪問可能需要兩次訪問到記憶體，因此建議使用2M甚至1G的大頁表來解決這個問題。
2.5總結
C10M的思想就是將控制層留給Linux做，其它資料層全部由應用程式來處理。沒有執行緒排程、沒有系統呼叫、沒有中斷等，當你的程式仍執行在Linux使用者空間，並僅僅對資料進行高效的分析和處理。
網絡卡：摒棄Linux核心協議棧，可以使用PF_RING，Netmap，intelDPDK來自己實現驅動；
CPU：使用多核程式設計技術替代多執行緒，將OS綁在指定核上執行；
記憶體：使用大頁面，減少訪問；
三、Intel® DPDK技術引入
Intel® DPDK全稱Intel Data Plane Development Kit，是intel提供的資料平面開發工具集，為Intel architecture（IA）處理器架構下使用者空間高效的資料包處理提供庫函式和驅動的支援，它不同於Linux系統以通用性設計為目的，而是專注於網路應用中資料包的高效能處理。目前已經驗證可以執行在大多數Linux作業系統上，包括FreeBSD 9.2、Fedora release18、Ubuntu 12.04 LTS、RedHat Enterprise Linux 6.3和Suse EnterpriseLinux 11 SP2等。DPDK使用了BSDLicense，極大的方便了企業在其基礎上來實現自己的協議棧或者應用。
需要強調的是，DPDK應用程式是執行在使用者空間上利用自身提供的資料平面庫來收發資料包，繞過了Linux核心協議棧對資料包處理過程。Linux核心將DPDK應用程式看作是一個普通的使用者態程序，包括它的編譯、連線和載入方式和普通程式沒有什麼兩樣。DPDK程式啟動後只能有一個主執行緒，然後建立一些子執行緒並繫結到指定CPU核心上執行。
3.1DPDK的組成
DPDK核心元件由一系列庫函式和驅動組成，為高效能資料包處理提供基礎操作。核心態模組主要實現輪詢模式的網絡卡驅動和介面，並提供PCI裝置的初始化工作；使用者態模組則提供大量給使用者直接呼叫的函式。
圖3 DPDK架構圖
EAL（Environment Abstraction Layer）即環境抽象層，為應用提供了一個通用介面，隱藏了與底層庫與裝置打交道的相關細節。EAL實現了DPDK執行的初始化工作，基於大頁表的記憶體分配，多核親緣性設定，原子和鎖操作，並將PCI裝置地址對映到使用者空間，方便應用程式訪問。
Buffer Manager API通過預先從EAL上分配固定大小的多個記憶體物件，避免了在執行過程中動態進行記憶體分配和回收來提高效率，常常用作資料包buffer來使用。
Queue Manager API以高效的方式實現了無鎖的FIFO環形佇列，適合與一個生產者多個消費者、一個消費者多個生產者模型來避免等待，並且支援批量無鎖的操作。
Flow Classification API通過Intel SSE基於多元組實現了高效的hash演算法，以便快速的將資料包進行分類處理。該API一般用於路由查詢過程中的最長字首匹配中，安全產品中根據Flow五元組來標記不同使用者的場景也可以使用。
PMD則實現了Intel 1GbE、10GbE和40GbE網絡卡下基於輪詢收發包的工作模式，大大加速網絡卡收發包效能。
圖4 DPDK的核心元件
圖4展示了DPDK核心元件的依賴關係，詳細介紹可以參考《Intel Data Plane Development kit：Software Architecture Specification》。
3.2DPDK的核心思想
3.2.1PMD
當前Linux作業系統都是通過中斷方式通知CPU來收發資料包，我們假定網絡卡每收到10個據包觸發一次軟中斷，一個CPU核心每秒最多處理2w次中斷，那麼當一個核每秒收到20w個包時就佔用了100%，此刻它沒做其它任何操作。
DPDK針對Intel網絡卡實現了基於輪詢方式的PMD（Poll Mode Drivers）驅動，該驅動由API、使用者空間執行的驅動程式構成，該驅動使用無中斷方式直接操作網絡卡的接收和傳送佇列（除了鏈路狀態通知仍必須採用中斷方式以外）。目前PMD驅動支援Intel的大部分1G、10G和40G的網絡卡。
PMD驅動從網絡卡上接收到資料包後，會直接通過DMA方式傳輸到預分配的記憶體中，同時更新無鎖環形佇列中的資料包指標，不斷輪詢的應用程式很快就能感知收到資料包，並在預分配的記憶體地址上直接處理資料包，這個過程非常簡潔。如果要是讓Linux來處理收包過程，首先網絡卡通過中斷方式通知協議棧對資料包進行處理，協議棧先會對資料包進行合法性進行必要的校驗，然後判斷資料包目標是否本機的socket，滿足條件則會將資料包拷貝一份向上遞交給使用者socket來處理，不僅處理路徑冗長，還需要從核心到應用層的一次拷貝過程。
3.2.2大頁表
為實現實體地址到虛擬地址的轉換，Linux一般通過查詢TLB來進行快速對映，如果在查詢TLB沒有命中，就會觸發一次缺頁中斷，將訪問記憶體來重新重新整理TLB頁表。Linux下預設頁大小為4K，當用戶程式佔用4M的記憶體時，就需要1K的頁表項，如果使用2M的頁面，那麼只需要2條頁表項，這樣有兩個好處：第一是使用hugepage的記憶體所需的頁表項比較少，對於需要大量記憶體的程序來說節省了很多開銷，像oracle之類的大型資料庫優化都使用了大頁面配置；第二是TLB衝突概率降低，TLB是cpu中單獨的一塊高速cache，一般只能容納100條頁表項，採用hugepage可以大大降低TLB miss的開銷。
DPDK目前支援了2M和1G兩種方式的hugepage。通過修改預設/etc/grub.conf中hugepage配置為“default_hugepagesz=1Ghugepagesz=1G hugepages=32 isolcpus=0-22”，然後通過mount –thugetlbfs nodev /mnt/huge就將hugepage檔案系統hugetlbfs掛在/mnt/huge目錄下，然後使用者程序就可以使用mmap對映hugepage目標檔案來使用大頁面了。測試表明應用使用大頁表比使用4K的頁表效能提高10%~15%。
3.2.3CPU親緣性
多執行緒程式設計早已不是什麼新鮮的事物了，多執行緒的初衷是提高整體應用程式的效能，但是如果不加註意，就會將多執行緒的建立和銷燬開銷，鎖競爭，訪存衝突，cache失效，上下文切換等諸多消耗效能的因素引入進來。這也是Ngnix使用單執行緒模型能獲得比Apache多執行緒下效能更高的祕籍。
為了進一步提高效能，就必須仔細斟酌考慮執行緒在CPU不同核上的分佈情況，這也就是常說的多核程式設計。多核程式設計和多執行緒有很大的不同：多執行緒是指每個CPU上可以執行多個執行緒，涉及到執行緒排程、鎖機制以及上下文的切換；而多核則是每個CPU核一個執行緒，核心之間訪問資料無需上鎖。為了最大限度減少執行緒排程的資源消耗，需要將Linux繫結在特定的核上，釋放其餘核心來專供應用程式使用。
同時還需要考慮CPU特性和系統是否支援NUMA架構，如果支援的話，不同插槽上CPU的程序要避免訪問遠端記憶體，儘量訪問本端記憶體。
3.3總結
總的來說，為了得到千萬級併發，DPDK使用如下技術來達到目的：使用PMD替代中斷模式；將每一個程序單獨繫結到一個核心上，並讓CPU從這些核上隔離開來；批量操作來減少記憶體和PCI裝置的訪問；使用預取和對齊方式來提供CPU執行效率；減少多核之間的資料共享並使用無鎖佇列；使用大頁面。
除了UDP伺服器程式，DPDK還有很多的場景能應用得上。一些需要處理海量資料包的應用場景都可以用上，包括但不侷限於以下場景：NAT裝置，負載均衡裝置，IPS/IDS檢測系統，TOR（Top of Rack）交換機，防火牆等，甚至web cache和web server也可以基於DPDK來極大地提高效能。
四、其它效能優化技術
除了DPDK提供的一些是思想外，我們的程式效能還能怎樣進一步提高效能呢？
4.1減少記憶體訪問
運算指令的執行速度是非常快，大多數在一個CPU cycle內就能完成，甚至通過流水線一個cycle能完成多條指令。但在實際執行過程中，處理器需要花費大量的時間去儲存器來取指令和資料，在獲取到資料之前，處理器基本處於空閒狀態。那麼為了提高效能，縮短伺服器響應時間，我們可以怎樣來減少訪存操作呢？
（1）少用陣列和指標，多用區域性變數。因為簡單的區域性變數會放到暫存器中，而陣列和指標都必須通過記憶體訪問才能獲取資料；
（2）少用全域性變數。全域性變數被多個模組或函式使用，不會放到暫存器中。
（3）一次多訪問一些資料。就好比我們出去買東西一樣，一次多帶一些東西更省時間。我們可以使用多運算元的指令，來提高計算效率，DPDK最新版本配合向量指令集（AVX）可以使CPU處理資料包效能提升10%以上。
（4）自己管理記憶體分配。頻繁呼叫malloc和free函式是導致效能降低的重要原因，不僅僅是函式呼叫本身非常耗時，而且會導致大量記憶體碎片。由於空間比較分散，也進一步增大了cache misses的概率。
（5）程序間傳遞指標而非整個資料塊。在高速處理資料包過程中特別需要注意，前端執行緒和後端執行緒儘量在同一個記憶體地址來操作資料包，而不應該進行多餘拷貝，這也是Linux系統無法處理百萬級併發響應的根本原因，有興趣的可以搜尋“零拷貝”的相關文章。
4.2Cache大小的影響
如今CPU早已不是在每次取資料和指令都先去訪問記憶體，而是優先訪問cache，如果cache命中則無需訪存，而訪問同一個cache中資料的開銷非常小。下圖展示了L1~L3級cache和記憶體的訪問延時。
圖5 三級Cache效能模型
Cache有效性得益於空間區域性性（附近的資料也會被用到）和時間區域性性（今後一段時間內會被多次訪問）原理，通過合理的使用cache，能夠使得應用程式效能得到大幅提升。下面舉一個實際的例子來讓大家理解cache大小對程式效能的影響。
|
程式碼示例 |
測試過程 |
|||||||||||||||||||
|
static int arr[1024*1024*1024]={0}; int k=16; void fun() { int i=0; for (i=0;i<1024*1024*1024;i+=k) arr[i]*=3; } int main() { fun(); return 0; } |
不同K值的測試結果：
|