基于Linux集群系統的并行通信性能研究*

王東煜,張佳樂，鄧志龍

(1.河北旅游職業學院 信息技術系,河北 承德,067000；2.廣西南寧職業技術學院,廣西 南寧530000)

集群系統實時并行測試裝置開發中,對軟件開發速度與軟件性能常常必舍其一。某些情況下，測試裝置已經疊加在現有的高層大量復制和通信包上，例如PVM機[1]和陣列編程語言ZPL，盡管延用存儲共享模式，但對分布式存儲而言，既可以使用PVM也可以使用MPI進行消息傳遞。而在另一些情況下，使用低層基元如Unix rsh、套接字應用程序編程接口。本文將單處理器并行編程語言、并元語言(CML)[2]擴展到一個集群系統。將CML語言從其基本功能語言格式翻譯成C編程語言代碼。現有的并行語言無法反映基于事件的CML語言的通信模式[3],故而采取對可用并行基元進行基準分析。研究Mosix、MIP-2及Linux基本工作機制：遠程進程調用（RPC）、信息和套接字等。由于這些系統所需的軟件類型各有不同，故選上述幾種系統進行本次實驗。MIP-2[4]是一種著名的消息傳遞系統，由資料庫、服務器和在操作系統應用程序構成。Mosix[5]由Linux內核擴展程序組成以便將程序透明遷移至遠程節點。盡管Mosix可用作吞吐量引擎，但這方面的研究人員[6]則建議充當集群計算機的并行應用程序，如分子動力學模擬。盡管從上述兩方面來說Linux操作系統是基礎性的，但本身存在低層機制，如套接字API和RPC2[7-8]，能夠直接支持并行處理。除了對性能進行研究，程序執行人員還應遵循配置簡單、編程、調試方便的原則。

本文在155 Mb/s ATM網絡計算機上將CORBA、ACE C++通信包資料庫與Socket模式C語言的軟件進行對照。針對醫療存儲區域的網絡應用，CORBA控制信號與套接字API調用整合在一起進行批量數據的傳輸，結果發現網絡信道速率與端對端應用程序的吞吐量不成比例，ATM網絡寬帶僅僅使用了40%。研究結果因此演變成所謂“吞吐量保留問題”的一個例證。

1 系統的運行環境

本文使用的集群系統包含經兩個以太網交換機連接起來的37個處理節點。形象地將這些節點稱為“堆”。每個節點是一個小型因子穿梭箱 （XPC SN41G2型號)，配置了AMD速龍XP 2800+巴頓內核 (CPU頻率2.1 GHz)，512 KB二級緩存，雙通道 1 GB DDR333 RAM。圖1中的節點通過24個端口千兆位以太網交換機 （D-Link生產，DGS-1024T型號）連接起來。每臺交換機是非阻斷網絡模式，允許任何一對端口之間同時具有全雙工千兆位帶寬。每臺交換機可以通過服務器上的獨立網卡聯網，便于集群系統分成兩個區間。本文將實驗范圍縮小至節點對節點的通信，而不考慮群體通信。不過在某些情況下，群體通信內的區別因子可能不是聯網行為而是軟件執行行為。

本文所用軟件Mosix[9-10]的open Mosix直接運行在標準的Unix通信機制上。實驗中使用Linux核心版本2.4.22；‘C’資料庫版本是 2.3.2；GNU gcc編輯軟件的版本3.2.3,MPICH版MPICH2-0.96p2。Mosix是一種搶占式進程遷移系統。由于運行在內核空間，Mosix對應用程序就變得無法察覺。但由于存在簡易API，所以應用程序可以注意到集群系統的配置及它們在系統內的位置。

2 實驗操作

Unix機制通常由Unix的BSD變體派生，數據以字節流形式傳輸；而系統V STREAMS由Unix的AT&T變體派生，數據以離散消息形式傳輸。基站通信和生成機制可以是Linux發布內容的部分,也可以是預寫軟件包的部分。語義上定義好的包裝層在實驗操作時圍繞軟件編寫好。不論實驗過程中的軟件是MPI、MOSIX或Unix機制中的哪一種，均會對輕量級層進行研究。

2.1 帶寬與延時實驗

基準代碼創建出兩個進程，彼此可以相互通信。帶寬實驗時，一個子進程充當發送端，另一個充當接收端。延時實驗時，單字節在兩個進程之間來回1萬次，等傳輸次數均等后用鐘表計算往返用時。這兩個進程可根據以下情況來創建：(1)視同一個處理器為父進程；(2)若有兩個不同的處理器，任何一個都不作父處理器；(3)若有兩個不同的處理器，選任意一個作父處理器。

2.2 動態進程的創建實驗

當大量復制一個新進程時，可以采取以下策略：

(1)允許系統自動選擇合適的節點：具有MPI-2和MOSIX的特征。

(2)對目標節點的選擇進行明確控制：具有RPC及rsh調用的特征。

執行MPI-2的當前MPICH-2時，只允許對進程進行隨機遷移，越過了定向遷移。而且，如果兩個進程一個接一個地大量復制，說明它們位于同一節點位置。MPI-2的確允許同時對兩個或多個同類進程進行大量復制，且在此情況下，當前的MPICH-2將這些進程分配到不同節點位置。

RPC可以將自動生成的服務器和顧客代碼打包塞入可執行進程里。這種情況不常見，但對一些自動代碼進行再編譯還是有可能的。因此，在每個節點位置，RPC并行應用程序都會有一個拷貝進程充當服務器，在特定節點位置也需要一個拷貝進程來進行初始化操作。每個RPC從一臺服務器上對新的應用程序副本創建子進程。

3 實驗結果

3.1 帶寬及延時測定

圖1給出各通信機制的帶寬檢測結果，當處理器內部通信和消息大小在10～100 B時，盡管套接字互聯網域選項被選來進行處理器間的通信，但套接字通信的效率最高。消息體積變大時，管道和fifos[11]成為最高效的機制，難以對它們進行區分。當消息≥10 000 B時，所有Unix機制的通信速率約為1 GB/s。

圖2是千兆位網絡連接的外部帶寬情況。由于Mosix代理機制的緣故，圖2中所有Mosix通信均通過主節點 1(即所謂的 Mosix通用主節點,縮寫為 UHN)來執行。由此可以發現所有的Mosix通信都不理想，其有效帶寬遠遠低于簡易套接字通信所達到的帶寬標準。套接字通信帶寬高達100 MB/s，可用帶寬的使用率達到80%，可見效率很高。

圖3中當發出端節點是個UHN時，Mosix帶寬性能有所提高。但Mosix帶寬的有效使用率仍遠低于套接字通信的。鑒于此MPI的通信性能穩定徘徊在兩區間之間，當大小在100 B～10 KB之間時，表現出特有的平穩狀態。主要原因在于MPI版本內部使用到一定緩沖面積。當信息大小超出閾值時，會有不同（及更高效）的機制來代替。

表1為通信延時檢測結果。由表1可知,當采取標準的Unix進程內通信（IPC）機制如管道、fifios、及 System V消息機制時，通信延時約為2 μs。這種通信僅適于同一臺處理器上的進程之間進行。同一臺處理器上互聯網域套接字通信導致的延時約為7 μs。表中的陰影部分表明延時數據是在Mosix操作時獲取到的。在單處理器上操作時，Mosix對通信延時的影響最小。表2只給出了單處理器帶/不帶Mosix機制的套接字通信延時性能的檢測結果。同時可知所需通信費用較少。

3.2 動態進程創建的檢測

對采取不同機制以“大量復制”一個新進程的用時進行基準分析。一臺1.8 GHz速龍XP 2200+PC（256 KB二級緩存、主內存配置同Linux處理器的）的用時如表3所示，這些主要是SSH用時。由于實驗不需確保內部安全，所以未在集群系統上安裝SSH。而是增加了一個安全層到RSH，系統性能未見明顯的“飆升”情況。

表1 通信延時檢測結果

表2 Linux集群系統上處理器間各大量復制機制的性能結果對照

當源節點（src）和終節點（dst）合二為一且為同一個時，MOSIX FORK幾乎與標準的FORK一樣高效。再看其他復制機制，情況依次如下：

鑒于單一大量復制通常耗時需1/10 s，所以不主張應用RSH、SSH、或 RUNON執行機制。RPC在一個千兆位的以太網上運行時十分高效——比其他通信機制更節約網絡資源。

表3給出了Linux集群系統上檢測的前大量復制遠程機制的性能執行實驗結果。計算MOSIX機制的平均用時，因為UHN位置的不同，結果也不同，因此就有了更簡單的排序方法，如表4。表4、表5中的“指數”一欄就是相對性能的一種簡單指代。鑒于性能幅度較大，采取粗度量單位較為妥當。指數1代指性能最佳。指數5表明速率降低了30%，依次類推等。

表3 Linux系統PC機處理器內各大量復制機制的性能結果對照

本文在對各通信機制的性能進行實驗后，根據研究結果對其進行了排序，如表5。有些機制在某些情況下表現不佳，較硬件標準還低，今后開發人員要特別注意這一點。實驗結果表明，MPI-2及Mosix無論在大量復制還是通信延時方面均存在廣泛可比性。不過，Mosix機制下的通信帶寬較低。若Mosix要成為實時或高帶寬應用程序之選，需要對之進行優化。鑒于本文旨在探討Mosix大量復制的透明度情況，故未對Mosix負荷平衡性能進行研究。低層通信機制的性能明顯優于高層軟件數據包的，這給因便捷或可遷移性而帶來的收益提出了質疑。

表4 實驗機器上各大量復制機制的性能執行結果排列

表5 實驗機器上各大量復制機制的簡易排序

總之，選用傳輸軟件用于集群系統仍是至關重要的決策。不論特定的并行計算模型有何優點，最終都得根據其性能表現情況做出判斷。但是，由于對傳輸軟件的重要性關注度更高，所以執行人員就更能解決性能方面的瓶頸問題。今后針對是什么樣的傳輸軟件架構才能提高通信性能和大量復制性能這一問題,還需進一步探討，可以從其底層結構如緩沖結構、軟件分層結構以及與操作系統內核交互作用情況等角度來研究。

[1]ABRAHAM A,THOMAS J.Distributed intrusion detection systems：a computational intelligence approach.In：Abbass HA,Essam D,editors.Applications of information systems to homeland security and defense.USA：Idea Group Inc.Publishers,2005：1051-1055.

[2]KABIRI P,GHORBANI A A.Research on intrusion detection and response：A survey.International Journal on Information Security,2005,1(2)：84-102.

[3]ALIPIO P,CARVALHO P,NEVES J.Using CLIPS to Detect Network Intrusion[J].Lecture Notes in Computer Science,2003：341-354.

[4]VIGNA G,ECKMAN S,KEMMERER R.The STAT tool suite[J].Proceedings of the DARPA Information Survivability Conference and Exposition 2000(2)：1046-1050.

[5]KANTZAVELOU I,KATSIKASS.An attack detection system for secure computer systems outline of the solution[C].Proceedings of the IFIP TC11 13th International Conference on Information Security,1997：123-135.

[6]DOYLE J,KOHANE I,LONG W,et al.Event recognition beyond signature and anomaly[C].Proceedings of the 2001 IEEE Workshop on Information Assurance and Security,2001：170-174.

[7]KIM D,NGUYEN H,PARK J.Genetic algorithm to improve svm-based network intrusion detection system[C].Proceedings of the 19th International Conference on Advanced Information Networking and Applications(AINA),2005(2)：155-158.

[8]CHAVAN S,SHAH K,DAVE N,et al.Adaptative neurofuzzy intrusion detection systems[C].Proceedings of the 2004 International Conference on Information Technology：Coding and Computing,2004(1)：70-74.

[9]HELMER G,WONG J,HONAVAR V,et al.Lightweight agents for intrusion detection[J].Journal of Systems and Software,2003(67)：109-122.

[10]LAZAREVIC A,ERTOZ L,KUMAR V,et al.A comparative study of anomaly detection schemes in network in trusion detection[M].Proceedings of the SIAM International Conference on Data Mining,2003：121-130.

[11]VALDES A,SKINNER K.Adaptive,model-based monitoring for cyber attack detection[M].Proceedings of RAID 2000：80-92.