百億億次級系統進程管理接口綜述

張 昆，張 偉，盧 凱，董 勇，戴屹欽

(國防科技大學計算機學院，湖南 長沙 410073)

1 引言

目前，高性能計算HPC(High Performance Computing)系統性能已經進入百億億次時代，各國都向著實現百億億次計算性能目標不斷行進，為提高經濟競爭力、推進工業生產、改善人類社會生活創造更多切實效益。

進程管理是高性能計算的一個組成部分，在結點數量較少的計算系統中，進程管理的可擴展性對應用程序運行沒有太大影響。但是，隨著系統規模擴大，傳統進程管理已經不能滿足海量處理器核的需求，迫切需要一種可擴展的管理方式，且可以提供進程交換信息的機制。為了解決該問題，在進程管理中引入進程管理接口PMI(Process Management Interface)，用于在啟動階段部署進程的通信方法。引入后的進程管理包括3個部分[2]：并行編程庫(例如MPI庫)、PMI庫和進程管理器。進程管理器是一個邏輯上的中心進程，用于管理進程啟動與進程間信息傳遞。PMI庫通過API接口提供進程交換信息機制。并行編程庫可以通過PMI API來訪問進程管理器提供的啟動進程、初始化進程等各類功能。

IBM發布的報告[1]指出，實現百億億次級計算系統有5大瓶頸，其中一項就是通信瓶頸。為了突破這一瓶頸，在進程之間快速建立通信機制成為一項重要的研究課題。百億億次系統內包含數萬結點與近千萬處理器核，以往PMI建立通信的方法無法滿足進程快速啟動的要求，大規模并行應用的啟動時間過長，成為限制系統運行效率、降低系統易用性的一個重要因素。

為了解決百億億次級系統的啟動問題，進程管理接口發展出PMIx(Process Management Interface-Exascale)的版本，以實現在30 s內啟動和連接大規模應用程序進程的總體目標[3]。PMIx定義了新的并行應用程序啟動順序，并針對大規模應用程序提出新的建立通信機制，力求縮短啟動時間，提高系統性能。

本文主要探討百億億次級計算性能目標下，進程管理接口啟動大規模并行應用程序的有效性，對比PMI-1、PMI-2和PMIx的工作機制與特點，分析PMIx對于作業快速啟動、系統高效運行的重要作用，以及在提升性能上做出的優化，并討論未來的發展方向。

本文第2節介紹進程管理接口的發展過程和大規模并行應用程序啟動過程，分析進程管理對于提高系統運行效率的重要意義；第3節分別介紹傳統的并行應用程序啟動順序和PMIx模式下的并行應用程序啟動順序，對比分析PMIx在改進啟動過程中所發揮的作用；第4節介紹為了提高系統性能，目前對PMIx所做的優化研究；第5節從啟動并行應用程序期間和運行時控制2個方面對未來PMIx的發展方向進行了說明。

2 背景

2.1 進程管理接口介紹

在現代高性能計算系統中，一個并行計算任務包含多個并行作業，每一個并行作業又包含一個或多個并行應用程序，而每一個應用程序則是一組二進制可執行文件的實例化。在系統中啟動一個并行應用程序主要包含以下幾步[4]：

(1)部署運行時環境。

該階段是在分配有作業的計算結點集上部署分布式的運行時環境RTE(Running Time Environment)。目前在大多數軟件堆棧中，該階段通常在分配的每一個計算結點上都創建一個RTE實例，用于后續生成和管理進程。

(2)啟動應用程序進程。

在分配有作業的計算結點上，RTE實例生成相應進程，并執行進程啟動。

(3)獲取預定義環境信息。

在此階段，RTE將自身已知的作業級信息提供給應用程序進程，如進程的rank信息、進程總數信息、共享同一計算結點的進程列表等。

(4)獲取動態環境信息。

在該階段，進程需要交換彼此特定于應用程序的數據信息。這些是不包含在階段(3)中但進程必須知道的信息，例如通信尋址信息，通過定義的全局操作，進程獲得此類信息。

目前，大多數的高性能計算軟件堆棧都采用進程管理接口來完成階段(3)與階段(4)的工作。并行應用程序進程通過PMI定義的API與RTE通信。PMI將信息組織成鍵值數據庫的形式，通過Put、Get和同步原語訪問數據庫。

在并行應用程序啟動過程中，最耗時的階段為階段(4)。當面對百億億次級系統時，進程數目龐大，所有進程彼此之間交換信息會花費大量時間，這對于實現快速啟動應用程序的目標十分不利。而PMIx則集中解決此階段問題，力求尋找獲取動態信息的新方法，盡可能將階段(4)中所需信息轉移到階段(3)中。通過減少進程交換信息操作的時間消耗，即使進程規模龐大，PMIx也可以達到快速啟動應用程序的目標，促進系統高效運行。

2.2 進程管理接口發展過程

隨著“異構MPI”項目的研究，各國致力于開發可應用于多臺不同類型計算機上的MPI，這就需要MPI程序能夠處理異構的通信協議、安全性機制和調度程序等[5]，這激發工作人員研究一類定義在MPI中使用的通用API，用來執行各類進程管理系統中的啟動、監視和控制進程的功能[6]。

第1代PMI(PMI-1)被廣泛應用在MPICH2[7]及其派生的MPI實現中[8]，其最初設計目標是利用一個接口減少進程管理器與MPI實現之間的耦合。PMI-1主要包含2個部分，一部分旨在協助MPI初始化過程中的引導活動，另一部分旨在支持MPI中的動態進程管理功能。PMI-1設計人員使進程管理器只提供MPI進程交換信息的通用機制。該機制由一個鍵值存儲KVS(Key-Value Store)組成。經過適當的同步操作，一個進程放入KVS的內容可以由另一個進程讀出。在PMI-1中，一個簡單的集體屏障功能保證了該類同步。一旦所有進程經過屏障操作，則認為所有數據都已寫入；并且一旦經過屏障操作釋放進程，進程就可以讀取所有數據。

但是，將PMI-1應用于現代高性能計算系統上時，卻暴露出PMI-1的局限性。雖然在PMI-1中有一個鍵值數據庫用于存取，但進程管理器無法向數據庫中添加系統信息，導致MPI進程不能從進程管理器中查詢此類信息。另外，PMI-1不能保證線程安全，在給定的PMI連接上，同時只能執行一個請求。并且，PMI-1中缺乏故障處理機制，無法在進程發生故障時重新生成進程。為了解決以上問題，開發人員設計出第2代進程管理接口(PMI-2)。

在PMI-2中，針對PMI-1的以下幾個方面進行了改進[2]：

(1)增加查詢功能。

PMI-2中加入了進程管理系統預定義的鍵。通過該類鍵，進程管理器將系統信息直接添加到鍵值庫中，MPI程序可以獲取與MPI進程相關的布局信息。

(2)擴大數據庫信息范圍。

PMI-1采用的是扁平化的數據庫，一個MPI進程不能限制它添加到數據庫中的鍵值的范圍。在此情況下，加入的信息都歸納為全局信息，進程無法單獨獲取僅與本地計算結點相關的子集信息。為了解決這個問題，PMI-2中引入了結點級別與全局級別的數據庫信息范圍，進程管理器可以更高效率地提取信息。

(3)增加線程安全。

PMI-1面臨多線程情況時，MPI實現調用PMI-1需使用適當鎖機制保護。但是，PMI-1中的鎖機制是粗粒度的，當PMI庫的一個查詢請求得到了進程管理器的響應后，其他線程就無法在該套接字上通信。PMI-2則對PMI-1中線程安全的限制進行了修改，MPI實現不需要確保一次僅有一個線程調用PMI。

(4)改善容錯機制。

當故障發生時，PMI-1沒有提供任何的進程重生機制進行處理。PMI-2提供了故障處理方法，利用重生的新進程取代同一進程組中的故障進程。

隨著超級計算機的發展，高性能計算系統面臨多層次的大規模并行處理，為了滿足百億億次級系統的要求，PMI社區開發出PMIx接口[3,9]。PMIx是專門設計用于支持百億億次級系統的進程管理接口，該接口以編程模型不可知的方式抽象出管理大規模應用程序和監視進程所必需的功能。

在PMI-2的基礎上，PMIx在功能上進行了進一步完善。相對于PMI-2中的數據庫信息范圍，PMIx將信息作用域增加到進程本地范圍、結點本地范圍、遠程范圍和全局范圍。另外，在PMI-1與PMI-2中，鍵值的數據類型僅定義為字符串，PMIx則擴展了數據表示，可對更多類型數據進行存儲。PMIx針對同步原語Fence和Get原語都加入了非阻塞版本，以降低操作延遲。同時，PMIx針對稀疏通信情況進行優化，提供按需數據交換模式，縮短通信時間。更為關鍵的是，針對啟動大規模并行應用程序，PMIx定義了新的啟動順序，力求降低傳統應用程序啟動過程時間成本，加快程序啟動。

3 大規模并行應用程序啟動過程優化

隨著高性能計算處理問題規模不斷增大，傳統并行程序啟動過程顯露出弊端。大規模應用程序的啟動時間成為一個不可忽視的問題，PMIx為了滿足百億億次級系統的要求，對傳統啟動順序進行調整，力求快速啟動應用程序。表1對比分析了傳統應用程序啟動順序與PMIx模式下的啟動順序。下面將對PMIx優化并行應用程序的啟動過程進行詳細介紹。

Table 1 Analysis of start sequence of parallel application表1 并行應用程序啟動順序分析

3.1 傳統并行應用程序啟動順序

傳統并行應用程序的啟動順序大致分為以下6個不同的階段，如圖1[10]所示。

第1階段：用戶將作業組織成腳本或交互會話請求的形式，其中包含完成作業所需的資源類型與數量描述。而后，用戶將作業提交給工作負載管理器WLM(WorkLoad Manager)，等待作業執行。

Figure 1 Traditional start sequence圖1 傳統啟動順序

第2階段： WLM根據作業優先級、可支配資源數目和資源調度算法，將資源分配給作業，并將分配結果通知控制資源分配的資源管理器RM(Resource Manager)守護進程[11,12]。RM守護進程接收通知后，一方面在文件系統FS(File System)里獲取應用進程二進制可執行文件，實例化作業進程，圖1中“Spawn Procs”代表生成進程過程；另一方面從文件系統中加載實例化進程所需的動態依賴庫。

可是，在進程數目龐大的情況下，由于大量結點的多個進程會同時進行請求庫操作，極易引發“庫檢索風暴”問題，導致文件系統壓力過大。

第3階段：進程實例化完成后，需要構建進程之間的通信機制。每個進程都要提供交互所需的本地通信信息，例如進程rank和通信端點地址。當進程獲取自身通信信息后，需要將該類信息發布到計算結點的本地代理上。

第4階段：結點的本地代理發現所有進程信息后，利用網絡上定義的全局操作[13]，完成結點與結點之間進程通信信息的全局交換過程，這一過程通常稱為名片交換或BCX(Business Card Exchange),圖1中“Global Xchg”代表該階段。這個階段是整個并行應用程序啟動階段中最耗時的部分。大部分的研究都關注如何開發更高效方法，以減少此過程的時間開銷。

第5階段：結點完成信息全局交換后，需要根據所獲得的通信信息構建通信通道。在這一階段，程序庫會基于本地代理上的信息進行基礎結構的組裝，例如將通信通道映射到其他進程。這個階段的時間花費是從本地結點的代理服務器上檢索連接和其他所需信息所花的時間，以及每個進程配置其本地網絡接口卡NIC(Network Interface Cards)所需的時間。

第6階段：執行全局的屏障操作，用來確認結點上的所有進程都已經構建完成通信結構，可以進行通信。雖然這一過程并沒有對數據進行處理操作，但此階段是除全局交換外，另一個耗時最多的階段。在該階段，需要觀察計算結點上的每一個進程是否都成功完成通信設置，另外還需要確認本地高速網絡也處于接收信息的狀態。只有經過該階段的屏障，才可以認為所有進程能夠進行交互。

隨著并行應用程序進程數目的大幅度增加，傳統的啟動過程中第4階段進程交換信息和第6階段確認進程狀態過程都會花費過多時間。為了實現在短時間內啟動大規模應用程序，PMIx對傳統應用程序啟動順序進行改進，力求消除全局交換的時間成本。

3.2 PMIx模式下并行應用程序啟動順序

傳統啟動過程中耗時最大的部分是全局交換信息與執行全局屏障階段，PMIx通過提供新的接口，調整并行應用程序的啟動順序，力求去除以上2個階段。修改后的并行應用程序理想啟動順序如下所示：

第0階段：該階段是針對系統資源進行的匯總過程，技術上來講并不是啟動過程的一部分，但資源目錄(包括交換機、網絡和結點拓撲等)對于應用程序調度以及有效完成啟動過程至關重要。在該過程中，PMIx以動態方式處理資源，并對資源目錄實時更新，從而保證啟動過程的順利完成。

第1階段：用戶將作業組織成腳本或交互會話請求的形式，其中包含完成作業所需要的資源類型與數量描述。而后，用戶將作業提交給WLM，等待作業執行。在該階段，WLM除了將請求記錄到適當的隊列中，還使用PMIx接口將請求傳遞到文件系統，以獲取所有用戶標識的可執行文件與支持庫。

第2階段：WLM根據作業優先級、可支配資源數目和資源調度算法，將資源分配給作業。分配通常發生在當前處理作業通知完成，啟動末尾操作之前。因此，在新作業調度開始之前，有一定的時間對資源分配進行預處理。

PMIx利用這段時間完成2個重要步驟。首先，它提供一個接口，WLM可以通過該接口通知FS分配情況，并將在初始階段確定的所需文件列表傳遞給FS。若此時存在可用緩存，文件系統將啟動進程用到的文件緩存到與分配結點相關內存位置，通過定位所需文件，緩解文件系統檢索壓力。

其次，WLM利用另一個PMIx接口將分配情況和作業描述都傳遞給子系統，并接收一個“blob”，其中包含每個子系統對作業的支持信息(例如網絡系統對進程通信的支持信息)。標記返回值來標識哪些值直接提供給結點上的本地資源，以及哪些作為環境變量傳遞給應用程序進程，環境變量在由特定進程初始化時會被資源識別。

第3階段：緩存所需文件并獲得網絡配置后，WLM將“blob”以及分配信息和資源目錄信息傳遞給已分配結點上的RM守護進程。在派生本地進程之前，每個RM守護進程都可以利用PMIx接口將配置信息傳遞給本地資源。RM守護進程向本地PMIx服務器注冊應用程序和本地進程，從而為進程提供與應用程序和本地環境有關的信息。完成操作后，RM守護程序將派生應用程序進程。

第4階段：在進程初始化期間，每個進程調用PMIx_Init函數連接到本地PMIx服務器。PMIx服務器通知RM進程連接，并返回本地RM守護進程在注冊期間提供的所有信息。

至此，啟動序列完成，進程已經獲取網絡系統的通信支持，可以自由通信。

但是，以上過程只是PMIx提出的一個理想啟動順序，目前還沒有在進程管理系統中完全實現。要完全消除傳統啟動過程中全局交換和全局屏障階段，需要對系統管理堆棧中的網絡庫與相應的事件處理機制做進一步改進[14,15]。

目前，PMIx提供了2個可用于提高啟動性能的方法[3,9]。首先，在BCX操作中刪除本地RM守護進程提供給每個進程的數據，從而大大減少BCX操作中包含的數據量，減少全局交換信息的時間。另外，PMIx提出一種直接名片交換DBCX(Direct Business Card Exchange)的替代連接方法，該方法根據需要獲取所需進程的名片來代替BCX操作。每個進程發布的數據都緩存在本地PMIx服務器上，當進程向特定進程請求名片時，進程首先檢查本地PMIx共享內存段，以查看數據是否已可用。如果不可用，則將請求傳遞到本地服務器，服務器隨后請求主機RM守護進程從指定進程的PMIx服務器中檢索數據。然后，本地PMIx服務器將數據提供給請求的客戶端進程。雖然DBCX通過消除BCX操作允許更快的啟動速度，但檢索特定進程名片信息的效率較低。因而，DBCX更適合稀疏通信的環境，對于密集通信，還存在需要改進的地方。

4 進程管理接口性能優化分析

PMIx啟動過程中耗時最長的部分是全局交換信息、建立通信機制的過程。為了快速啟動大規模并行應用程序，目前對于PMIx的研究，大部分都集中在改進全局交換、建立大規模進程通信通道方面，研究者們針對PMIx啟動過程中的各個階段做出不同方面的優化。本節從下列幾個方面介紹目前對于PMIx所進行的優化研究：(1)優化PMIx數據庫伸縮性；(2)優化數據表示形式；(3)優化PMIx運行時環境。

4.1 優化PMIx數據庫伸縮性

在進程管理接口提供的交互方式里，資源管理器與應用程序的信息交換是通過鍵值數據庫KVDb(Key-Value Database)來進行的。應用程序進程通過PMI提供的Put原語將數據提交到KVDb中，利用特定的同步原語使數據庫接收所有進程Put的數據，而后進程調用Get原語從KVDb中獲取所需信息。

結點內的KVDb訪問是影響PMI性能的主要原因之一，主要體現在Get原語的延遲問題。Chakraborty等人[16]對資源管理器SLURM中PMI-2實現的可伸縮性進行分析，將客戶進程與服務器的通信定義為影響通信效率的一個關鍵限制，并且他們也探討了利用共享內存機制實現KVDb的優勢，主要包含以下幾點：

(1)內存消耗可伸縮：傳統方式在應用程序的每一個進程上都復制一次KVDb的內容，導致占用過多內存。利用共享內存機制，只需要在計算結點上存儲一次KVDb內容，可減少存儲量。

(2)更優的并行性：共享內存允許客戶端在不涉及服務器的情況下獨立訪問KVDb。

(3)延遲更低：操作被允許可以按照CPU速度進行處理。

通過對PMI數據庫伸縮性進行優化，從而降低Get原語的延遲，加快進程數據訪問，提升資源管理器性能。與PMI-1和PMI-2相比，PMIx提供了更優的數據訪問能力，一方面對作業級信息進行擴展，資源管理器可以直接獲得作業環境的信息；另一方面，PMIx允許按需獲取信息，在PMIx_Get中可以從KVDb中獲得指定進程的信息。

PMI中原有的鎖機制是POSIX線程[17]中的Read/Write locks(RW-locks)鎖機制，該類鎖的可伸縮性十分有限。為了進一步減少PMIx_Get操作延遲，Polyakov等人[18]基于文獻[19]中的靜態算法在PMIx的2.1版本中提出2N-lock鎖機制。通過引入信號鎖解決靜態算法中寫入器易餓死的問題，信號鎖不易被讀取器獲取，但可以被寫入器獲取。寫入器需要首先獲得所有信號鎖，然后獲取讀取鎖進行寫入操作。

另外，Polyakov等人[18]發現PMIx_Get中的線程轉換也是影響性能的另一個限制因素。由于在PMIx 2.1版本的參考實現里，共享內存組件無法訪問PMIx實現的全局狀態，作者提出了新的線程安全轉換方案：在PMIx_Get獲取所需數據后，再進行線程shift操作，從而避免讀寫數據過程中的線程shift操作帶來的延遲。對比原有實現，新提出的PMIx主機通信的鎖定與線程安全方案，在168 PPN(Processors Per Node)情況下，最高可減少PMIx_Get操作66倍的延遲。

4.2 優化數據表示形式

這一部分的優化是針對PMIx啟動過程中全局交換信息階段的數據量大小進行的，通過精簡交換信息的數據量，去除不必要的重復信息，從而緩解數據交換的壓力，加速信息交換過程。并且，更精簡的數據表示形式也可以減少存儲空間占用，這對于大規模并行程序來說效果更為明顯。

表2針對PMIx啟動過程中涉及到的在數據表示形式方面所做的不同優化方式的效果進行了總結，簡要介紹了各類方法的優化對象和優化方式，對比優化前與優化后數據表示形式的字節大小，分析所提出方法的優化效果，本節后續將對各類優化方法的具體內容進行詳細介紹。

Table 2 Summary of data representation optimization mechanisms表2 數據表示形式優化機制總結

4.2.1 優化通信地址信息

Polyakov等人[20]使用基于UCX(Unified Communication X)通信的PMIx高性能軟件棧對數據布局進行優化。UCX是一個高級通信庫，其地址信息中包含進程建立連接過程中用到的所有信息，如通信地址、地址長度、通道特征等。Polyakov等人[20]通過去除地址表示中的通道特征和地址長度等通用信息，將通信實體地址信息大小從51 B降低到21 B，優化了60%。

4.2.2 優化進程交換數據表示

在PMIx中，進程交換全局信息時，通過調用運行時環境的Fence函數確保KVDb的全局信息同步，這是整個并行應用程序啟動過程中最耗時的部分[21]。Fence函數通過交換每個運行結點上的數據塊來保證信息同步，數據塊由頭部信息與進程組件信息組成，進程組件信息按照進程rank排序，每一個進程組件由進程標識符與進程鍵值對組成。為了減少交換的數據量信息，Polyakov等人[20]對數據塊中各部分進行了如下優化：

(1)優化進程標識符表示。

一直以來，進程標識符是由進程namespace與rank組成。namespace字段由運行時環境所分配，在不同的運行時環境中，該字段的長度是不同的。在Open RTE(Run Time Environment)環境中，namespace字段大小為10 B，而在SLURM中，該字段至少為21 B。Polyakov等人對PMIx_Fence進行分析發現，參與同步操作的進程必須是同一namespace中的，這就表示參與同步操作的進程可組成一個固定序列，只需用一個大小為4 B的序列號標識進程即可，減少了進程標識符的內存占用。

(2)優化鍵值對表示。

在2.1版本及以前的PMIx參考實現里，一個鍵值對中key的表示形式為(namespace,rank,key-name)，并且PMIx_Get原語可以識別請求key所在的進程的rank值，這導致相同的key可能在數據塊中重復出現。本文通過建立關于key的索引表，并只用key在表中的整數索引(大小為4 B)標識key的位置，對鍵值對表示進行優化。對于每個結點上N個進程(PPN為N)的情況，若key字段大小為s個字節，另外需要4個字節來表示key的長度，則一個key共需占用N*(s+4)個字節；引入索引表后，上述情況只需占用(s+4)+4*N個字節，對比減少占用s*(N-1)-4個字節，對于高性能計算軟件堆棧，優化效果明顯。

(3)優化數值編碼方式。

在2.1版本及以前的PMIx參考實現里的數值表示中，為了防止數據溢出，通常采用一個相比數值實際大小要大很多的數據類型來表示數據。例如對于鍵值對中的value字段，不論鍵值真實大小，統一采用uint64數據類型定義鍵值，在內存中占用[21;256] B。這種方法在一定程度上造成了空間浪費，當進程數目較多時，浪費更為明顯。本文采用Little-Endian Base 128(LEB128)[22]編碼方式，僅把所需要的字節打包到緩沖區中，避免了數據類型造成的多余空間浪費，優化了數據占用空間。

4.3 優化PMIx運行性時環境

針對分布式計算運行時環境的問題，目前已經有了一系列的研究，每一類方法都集中解決一類特定問題。MPICH提供了多種運行時環境[23]，例如Hydra[24]、MPD(MultiPrupose Daemon)[25]、Gforker等。Hydra可以很好地擴展單個結點上的大量進程，與混合編程模型可有效交互；雖然Hydra可以檢測和報告MPI進程失敗，但無法處理故障進程。MPD通過一個環形拓撲連接結點，然而MPD彈性差，如果2個結點故障會將所有結點分成2個單獨的結點組，從而阻止故障結點的通信；另外，MPD也不具備可伸縮性。

OPEN RTE[26]是OPEN MPI[27]的運行時環境，用于啟動、監視和殺死并行作業，通過各種拓撲連接守護進程，但是通信并不可靠。PRETE運行時環境是PMIx規范的參考實現，技術上屬于OPEN RTE的一個分支，繼承了OPEN RTE中啟動和監視MPI作業的大部分功能，能夠部署各種各樣的并行應用程序和工具。

針對不同的運行時環境，在PMIx中可進行不同的優化措施，目前已有的針對運行時環境優化的研究有：

Polyakov等人[20]針對SLURM[28]運行時環境中PMIx_Fence操作進行優化，將PMIx_Fence與MPI Allgatherv[29]操作對比分析，采用調整后的Bruck級聯算法作為Fence操作。作者在108個結點上進行實驗，以SLURM 18.08作為運行時環境，利用提出的集體算法與原有的樹形Fence操作、環形Fence操作進行實驗對比。結果表明，在108個結點上，當消息的規模從20字節擴展到214字節時，相比樹形算法和環形算法，集體算法有效降低了Fence操作延遲。

為了在系統上有效運行計算任務，處理系統故障具有重要意義[30]。Zhong等人[31]針對PMI-x的參考運行時環境(PRRTE)中的故障處理進行研究，實現一種高效運行時故障檢測，每個參與者只在可恢復的環拓撲之后觀察單個對等點，利用多個重疊的拓撲進行優化檢測與傳播，最小化故障檢測開銷并保證框架的可伸縮性，加快進程故障處理。作者提出的方法權衡了系統開銷、檢測效率和檢測風險之間的復雜關系，既可以承受結點與故障檢測的高頻特性，同時具有較低程度的拓撲結構，為在大型系統上有效進行故障管理提供了新的思路。

4.4 進程管理接口優化機制效果對比

4.1～4.3節中介紹了目前PMIx在數據庫伸縮性、數據表示形式、運行時環境3方面所做的優化研究，表3對這3類優化機制效果進行了綜合分析，探討每一類優化機制的側重點方向，通過對比為未來優化方向提供研究思路。

Table 3 Comparison and analysis of different PMIx optimization mechanisms表3 不同PMIx優化機制效果對比分析

5 結束語

為了早日實現百億億次計算目標，PMIx社區與各國研究人員一直致力于改進PMIx，以實現在更短時間內啟動大規模進程的啟動目標。本節主要從PMIx對于并行應用程序啟動期間和運行時控制2個方面對PMIx未來的發展方向進行介紹。

5.1 并行應用程序啟動期間

并行應用程序啟動期間，在所有計算結點上實例化可執行文件及其依賴庫的時間是影響啟動過程的重要因素，當大規模進程同時請求加載一個依賴庫時，容易引發“庫檢索風暴”問題。

目前，PMIx正在定義新的API，優化可執行文件的實例化。為了緩解文件系統的檢索壓力，未來PMIx正致力于通過預先定義的接口對作業腳本進行分析，提前獲得所執行作業的動態依賴庫信息，調用腳本級的指令提前發現所需的依賴文件，預定位到存儲管理器中，并利用二進制文件執行動態庫的加載。

在進程建立通信階段，探索新的進程通信方式，當前發布的PMIx 3.0版本提供了為進程分配靜態端口的函數。在未來的資源管理器中，可以利用此類接口取消進程動態分配通信端口的過程，從而消除全局交換信息階段帶來的時間成本問題。

5.2 運行時控制

目前PMIx對于運行時控制的優化主要集中于對存儲數據方面的控制能力，例如對于并行應用程序數據重定位或存儲策略的能力，目前這方面的研究還處于起步階段，在未來還有很大改進空間。當前，PMIx正致力于發展以下幾個方面：

(1)增強并行應用程序進程向資源管理器匯報數據存儲情況，并將當前系統可用的資源實時更新通知到資源管理器。

(2)加強并行應用程序的進程向資源管理器查詢當前數據的存儲情況，快速獲取進程所需數據的位置以及當前資源管理器存儲方式等信息。

(3)進一步加強PMIx對于事件的處理機制，利用觸發器及時激發事件進行事務處理；提高故障處理能力，合理應對系統運行過程中可能出現的各類問題，加強對于數據庫更新的管控能力。