一種提升應用交付通訊平臺多進程程序性能的方法
【專利摘要】本發(fā)明公開了一種提升應用交付通訊平臺多進程程序性能的方法，所述方法包括：根據源IP將數據包哈希到網卡隊列；綁定所述網卡隊列中的數據包到相應的CPU核；將所述CPU核上接收的數據包綁定相應的進程進行處理；為每個進程分別創(chuàng)建服務程序，設置所述服務進程為REUSEPORT選項，并綁定IP和端口；運行修改后的服務程序，根據服務進程的數量調整多隊列網卡啟用的隊列數；所述每個服務進程分別綁定在一個CPU核上。本發(fā)明能夠均衡網卡硬中斷、軟中斷，保證接收和發(fā)送數據包的CPU核是同一個CPU核，從而提高CPU的緩存命中率。
【專利說明】一種提升應用交付通訊平臺多進程程序性能的方法

【技術領域】
[0001 ] 本發(fā)明涉及計算機網絡技術，尤其涉及一種提升應用交付通訊平臺多進程程序性能的方法。

【背景技術】
[0002]CPU緩存是位于CPU與內存之間的臨時存儲器，主要是為了解決CPU運算速度與內存讀寫速度不匹配的矛盾。CPU緩存按照數據讀取順序與CPU結合的緊密程度，可分為一級緩存、二級緩存。其中，一級緩存又可以分為數據緩存和指令緩存，用來存放數據及對執(zhí)行這些數據的指令進行及時解碼。
[0003]通常多核處理器的每個核有一個較小的獨立的一級緩存，另外所有的核共享一個較大的二級緩存。程序訪問數據的速度如下:
[0004]如果程序訪問的數據在本核的一級緩存中，則訪問該數據的速度最快。
[0005]如果程序訪問的數據在二級緩存中，則訪問該數據較快。
[0006]如果程序訪問的數據不在一、二級緩存中，因CPU運算速度比內存讀寫速度快，CPU需花費很長時間來從內存調取數據，訪問很慢。
[0007]同一個數據存儲在多個核的一級緩存上時，有一個核修改該數據，會導致其他核上的該數據的緩存失效。
[0008]目前，多核處理器環(huán)境下，單隊列網卡和多隊列網卡都有不同程度上提高CPU緩存命中率的機制。
[0009]單隊列網卡下提高CPU緩存命中率的機制
[0010]單隊列網卡機制采用RPS (Receive Packet Steering接收數據包轉向)+RFS (Receive Flow Steering接收數據流轉向)機制優(yōu)化數據流。RPS實現了數據流的哈希歸類，同時把軟中斷負載均衡到各個CPU。由于RPS只是單純的把同一流的數據包分發(fā)給同一個CPU核來處理，可能會造成分發(fā)數據流的CPU核和執(zhí)行處理該數據流的應用程序的核不是同一個，此時，數據包均衡到不同的CPU，應用程序所在的CPU和軟中斷處理的CPU不同，嚴重影響CPU緩存效率。RFS解決了該問題，它把接收到的數據包送達應用所在的CPU上，提高CPU緩存命中率。其中，RPS與RFS的示意圖如圖1a和圖1b所示。
[0011]單隊列網卡機制的RPS、RFS雖然能均衡網卡軟中斷處理，但硬中斷會成為系統(tǒng)性能的瓶頸。
[0012]多隊列網卡下提高CPU緩存命中率的機制
[0013]多隊列網卡機制米用RSS(Receive-side Scaling 接收端擴展)、XPS(TransmitPacket Steering發(fā)送數據包轉向)、REUSEP0RT (端口重用)等方法優(yōu)化數據流。多網卡下，有多個收、發(fā)隊列。網卡收到數據包后，使用網絡層RSS哈希算法(基于IP的算法)或者傳輸層RSS哈希算法(基于端口的算法)把數據包發(fā)到各個隊列，然后發(fā)送中斷信號到隊列中處理隊列中斷的CPU核上，從而使得該核執(zhí)行驅動指令，收取數據包到系統(tǒng)。RSS原理如圖2所示。
[0014]XPS機制中，為每個CPU準備一個發(fā)送隊列映射表，表示該CPU發(fā)送的數據包，只能用該發(fā)送隊列映射表上設置的隊列發(fā)送，用戶可以設置每個CPU的發(fā)送隊列映射表。通過限定CPU發(fā)送隊列的數量，相當于綁定CPU到發(fā)送隊列，提高了 CPU緩存效率。圖3是XPS的實例圖，圖中每個處理器只能用一個隊列發(fā)送數據包。
[0015]傳統(tǒng)的多進程模型中，這些進程共享服務器socket (套接字)?？蛻舳苏埱蟮竭_時，各個進程競爭獲得該請求，此時客戶端請求由哪個進程處理是不確定的。為了解決這一問題，為創(chuàng)建的socket設置REUSEP0RT (端口重用)選項，使得多個進程可同時綁定同一個IP和端口，客戶端請求根據(源IP，源端口，目的IP，目的端口)哈希到達服務器進程，消除了 accept (接收)驚群問題，提高了系統(tǒng)效率。圖4所示REUSEP0RT的實例圖，4個進程綁定相同的IP和端口對客戶端外提供服務。
[0016]在多核處理器、多隊列網卡環(huán)境下，采用以上方法雖然能提高程序的處理效率，但確不能保證接收數據包的CPU核和發(fā)送數據包的CPU核是同一個CPU核，會導致CPU緩存效率低，系統(tǒng)性能下降。


【發(fā)明內容】

[0017]為解決上述技術問題，本發(fā)明的目的是提供一種多核處理器、多隊列網卡環(huán)境下提升應用交付通訊平臺多進程程序性能的方法，應用交付通訊平臺中處理網卡隊列硬中斷、軟中斷、協議棧收發(fā)數據包、應用程序處理等在一個核上完成，并通過集中數據包的處理，提高系統(tǒng)CPU緩存效率，最終提高整個系統(tǒng)的性能。
[0018]本發(fā)明的目的通過以下的技術方案來實現:
[0019]一種提升應用交付通訊平臺多進程程序性能的方法，該方法包括:
[0020]根據源IP將數據包哈希到網卡隊列；
[0021]綁定所述網卡隊列中的數據包到相應的CPU核；
[0022]將所述CPU核上接收的數據包綁定相應的進程進行處理；
[0023]為每個進程分別創(chuàng)建服務程序，設置所述服務進程為REUSEP0RT選項，并綁定IP和端口 ；
[0024]運行修改后的服務程序，根據服務進程的數量調整多隊列網卡啟用的隊列數；所述每個服務進程分別綁定在一個CPU核上。
[0025]與現有技術相比，本發(fā)明的一個或多個實施例可以具有如下優(yōu)點:
[0026]能夠均衡網卡硬中斷、軟中斷，保證接收和發(fā)送數據包的CPU核是同一個CPU核，從而提高CPU的緩存命中率。

【專利附圖】

【附圖說明】
[0027]圖1a和圖1b是現有技術提供的RPS/RFS和RPS結構示意圖；
[0028]圖2是現有技術提供的RSS結構原理圖；
[0029]圖3是現有技術提供的XPS實例圖；
[0030]圖4是現有技術提供的REUSEP0RT實例結構圖；
[0031]圖5是本發(fā)明提供的方法流程圖；
[0032]圖6是本發(fā)明建立連接時的示意圖；
[0033]圖7是本發(fā)明建立連接后的示意圖。

【具體實施方式】
[0034]為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結合實施例及附圖對本發(fā)明作進一步詳細的描述。
[0035]如圖5所示，為提升應用交付通訊平臺多進程程序性能的方法，該方法包括:
[0036]步驟10根據源IP將數據包哈希到網卡隊列；
[0037]為了保證同一個源IP的數據包硬中斷、軟中斷都交由同一個處理器核處理，替換Linux內核網卡驅動模塊中默認基于源IP、源端口、目的IP、目的端口的RSS哈希算法為源IP地址哈希算法。
[0038]步驟20綁定所述網卡隊列中的數據包到相應的CPU核；
[0039]第N個網卡隊列上的網卡硬中斷、軟中斷交給第N個CPU處理。設置網卡的第N個隊列的硬中斷到第N個CPU核；軟中斷默認與硬中斷運行在同一個CPU核上。
[0040]步驟30將所述CPU核上接收的數據包綁定相應的進程進行處理；
[0041]第N個CPU上接收的數據包交給第N個進程處理。修改REUSEP0RT哈希算法，使其哈希的結果與步驟10中哈希算法的哈希結果相同。
[0042]步驟40為每個進程分別創(chuàng)建服務程序，設置所述服務進程為REUSEP0RT選項，并綁定IP和端口 ；然后調用accept等待客戶端連接。
[0043]步驟50運行修改后的服務程序，根據服務進程的數量調整多隊列網卡啟用的隊列數；所述每個服務進程分別綁定在一個CPU核上。
[0044]在修改后的Linux系統(tǒng)上運行修改后的服務程序，假設進程數量為N，則調整多隊列網卡所啟用隊列數為N，且每個服務器進程分別綁定在一個核上。
[0045]建立連接時的處理情況，如圖6所示:系統(tǒng)上有N個核，每個核上運行一個服務器進程，多隊列網卡啟用了 N個隊列；當客戶端請求到達網卡后，網卡根據客戶端源IP哈希到下一個核上，經過在該核上的協議棧處理后，REUSEP0RT哈希算法同樣使用網卡所使用的哈希算法根據該客戶端的源IP，把該客戶端的請求交給下一個服務器進程處理。
[0046]建立連接后的處理情況，如圖7所示:當連接建立后，客戶端的數據包經過網卡哈希，交由下一個核處理，然后直接交由運行在該核上的服務器進程處理。
[0047]雖然本發(fā)明所揭露的實施方式如上，但所述的內容只是為了便于理解本發(fā)明而采用的實施方式，并非用以限定本發(fā)明。任何本發(fā)明所屬【技術領域】內的技術人員，在不脫離本發(fā)明所揭露的精神和范圍的前提下，可以在實施的形式上及細節(jié)上作任何的修改與變化，但本發(fā)明的專利保護范圍，仍須以所附的權利要求書所界定的范圍為準。
【權利要求】
1.一種提升應用交付通訊平臺多進程程序性能的方法，其特征在于，所述方法包括: 根據源IP將數據包哈希到網卡隊列； 綁定所述網卡隊列中的數據包到相應的CPU核； 將所述CPU核上接收的數據包綁定相應的進程進行處理； 為每個進程分別創(chuàng)建服務程序，設置所述服務進程為REUSEPORT選項，并綁定IP和端Π ； 運行修改后的服務程序，根據服務進程的數量調整多隊列網卡啟用的隊列數；所述每個服務進程分別綁定在一個CPU核上。
2.根據權利要求1所述的提升應用交付通訊平臺多進程程序性能的方法，其特征在于，每個通訊數據處理隊列綁定一個單獨的CPU核；每個進程綁定一個單獨的CPU核。
3.根據權利要求1所述的提升應用交付通訊平臺多進程程序性能的方法，其特征在于，網卡接收到的數據包經過源地址哈希算法后，哈希進入某個通訊數據處理隊列，并交由綁定該通訊數據處理隊列的CPU核上的進程來處理，數據處理完后經由該CPU核上綁定的發(fā)送隊列返回給客戶端。
4.根據權利要求1所述的提升應用交付通訊平臺多進程程序性能的方法，其特征在于，客戶端發(fā)往應用交付通訊平臺程序的數據包到達網卡的某隊列后，觸發(fā)網卡中斷，網卡中斷、數據包分發(fā)、協議棧和應用程序綁定在同一個CPU核上。
5.根據權利要求1所述的提升應用交付通訊平臺多進程程序性能的方法，其特征在于，運行在第N個CPU核上的應用交付通訊平臺進程使用網卡的第N個收隊列和第N個發(fā)送隊列收發(fā)數據包。
【文檔編號】G06F9/50GK104281493SQ201410510222
【公開日】2015年1月14日 申請日期:2014年9月28日 優(yōu)先權日:2014年9月28日
【發(fā)明者】高明, 張廣龍, 彭建章 申請人:般固(北京)科技股份有限公司