劉 軼，高玉林，張國振

(北京航空航天大學(xué) 計算機學(xué)院， 北京 100191)

高性能計算(high performance computing，HPC)系統(tǒng)廣泛應(yīng)用于國防建設(shè)、科學(xué)研究以及國民經(jīng)濟等重要領(lǐng)域，這些重要領(lǐng)域內(nèi)應(yīng)用需求的日益增長促進了高性能計算系統(tǒng)的迅速發(fā)展和規(guī)模增長。日本于2020年6月發(fā)布的超級計算機Fugaku[1]擁有158 976個節(jié)點，節(jié)點處理器包含48個計算核及4個輔助核，系統(tǒng)峰值浮點性能高達513 PFLOPS。神威·太湖之光[2]是性能優(yōu)越的國產(chǎn)超級計算機，擁有40 960個處理器，共10 649 600個處理器核，系統(tǒng)峰值性能達125.436 PFLOPS。

隨著高性能計算系統(tǒng)規(guī)模的日益龐大以及系統(tǒng)內(nèi)組件數(shù)量的迅速增加，硬軟件復(fù)雜性不斷提高、系統(tǒng)日益復(fù)雜，這使得高性能計算系統(tǒng)的平均無故障時間(mean time between failures，MTBF)越來越短。HPC系統(tǒng)上通常運行并行程序，由于參與并行程序運行的節(jié)點數(shù)巨大、程序運行時間長，系統(tǒng)MTBF的降低使得程序在運行過程中發(fā)生硬軟件故障的可能性也隨之增加。突發(fā)的系統(tǒng)硬軟件故障，如節(jié)點死機、操作系統(tǒng)崩潰、互連網(wǎng)絡(luò)故障等，會影響程序執(zhí)行，甚至導(dǎo)致程序運行失效。

消息傳遞接口(message passing interface, MPI)是HPC系統(tǒng)中用于進程間通信的并行編程接口。盡管MPI應(yīng)用廣泛，但它自身并不具備容錯機制。如果其中一個計算節(jié)點崩潰，整個 MPI 并行程序?qū)罎?。在HPC系統(tǒng)中，失效的程序通常比成功的程序消耗更多的資源。

大多數(shù)HPC系統(tǒng)使用作業(yè)管理系統(tǒng)(如Slurm[3]、PBS[4])來管理資源，并執(zhí)行不同用戶的多個作業(yè)。程序執(zhí)行過程中，用戶不能直接與程序進行交互。同時，作業(yè)管理系統(tǒng)只能反映作業(yè)的排隊、運行狀態(tài)，并不能發(fā)現(xiàn)程序在運行時出現(xiàn)的所有異常情況。當程序自身存在編程bug，如死鎖、死循環(huán)等情況時，程序不會被作業(yè)管理系統(tǒng)中止，這將占用計算資源，并且影響程序的正常執(zhí)行。在硬軟件故障方面，除了元器件和部件故障導(dǎo)致死機、程序崩潰等常見的故障之外，還有一些間歇性的故障。例如，內(nèi)存工作不穩(wěn)定或接觸不良可能導(dǎo)致系統(tǒng)故障。這些故障會偶發(fā)出現(xiàn)，具有不確定性。

雖然用戶可以在小規(guī)模下調(diào)試程序，但是許多問題只有在進程足夠多時才會出現(xiàn)，而且某些調(diào)試工具雖可以收集程序狀態(tài)，但不能提供參與程序執(zhí)行的計算節(jié)點的硬軟件狀態(tài)。因此，如果程序在HPC上運行失敗，用戶應(yīng)該首先區(qū)分運行失敗是由于程序自身bug還是系統(tǒng)硬軟件故障。

Slurm是一個大規(guī)模Linux機群的輕量級開源資源與作業(yè)管理器，可以為用戶提供對機群資源的共享訪問。由于輕量且高效的性能，Slurm受到超算中心的關(guān)注，超過60%的500強超級計算機使用Slurm[3]。本文基于Slurm提出一種并行程序運行故障原因識別系統(tǒng)，將程序運行失效的原因識別為系統(tǒng)硬軟件故障或程序自身bug，減輕了調(diào)試過程的平均故障間隔時間縮短對未來百億億級超級計算機的影響，并提高了調(diào)試大型并行程序的效率。

1 作業(yè)管理系統(tǒng)Slurm簡介

Slurm是一種開源的Linux機群管理和作業(yè)調(diào)度系統(tǒng)。它具有三個主要功能：首先，它提供了一個框架，用于在高性能計算機群上提交、啟動和監(jiān)視分配所有計算節(jié)點上的作業(yè)；然后，它使用排隊策略管理等待資源分配的作業(yè)隊列，以提高計算節(jié)點資源的利用率；最后，它統(tǒng)籌分配計算節(jié)點的資源給用戶的作業(yè)，使得用戶的作業(yè)可以運行。

Slurm的組織架構(gòu)如圖1所示。Slurm主控制節(jié)點運行slurmctld守護程序，用于管理資源、調(diào)度和監(jiān)視作業(yè)。當主控制節(jié)點出現(xiàn)故障時，備用控制節(jié)點對系統(tǒng)進行管理，提高了Slurm的容錯性。每個計算節(jié)點都運行slurmd守護程序，該守護程序負責(zé)等待和執(zhí)行slurmctld分配的作業(yè)，并監(jiān)視作業(yè)的狀態(tài)、響應(yīng)slurmctld對機器狀態(tài)和作業(yè)信息的請求、發(fā)送機器狀態(tài)和作業(yè)狀態(tài)的變化到slurmctld。slurmstepd由slurmd守護進程在作業(yè)啟動時生成，并在作業(yè)完成后終止。slurmstepd是Slurm的作業(yè)步管理進程，負責(zé)管理作業(yè)步的輸入、輸出(stdin、stdout和stderr)及信號處理。

圖1 Slurm組成結(jié)構(gòu)Fig.1 Slurm architecture

Slurm用戶命令包括sbatch，srun，sinfo，squeue和scontrol等。sbatch和srun用于提交作業(yè)；sinfo和squeue可以報告系統(tǒng)所有計算節(jié)點狀態(tài)和作業(yè)隊列中的作業(yè)狀態(tài)；scontrol用于監(jiān)視和修改機群中的配置和狀態(tài)信息。當普通用戶在Slurm上調(diào)試大型并行程序時，只能通過Slurm提交待調(diào)試的作業(yè)，等待Slurm分配計算資源，最后等待執(zhí)行結(jié)果。在程序執(zhí)行期間，普通用戶只能使用squeue和scontrol show job命令查看作業(yè)的狀態(tài)，不能得到節(jié)點硬軟件狀態(tài)的數(shù)據(jù)。在節(jié)點失效、運行超時等情況下，scontrol show job命令可以輸出作業(yè)的信息(如NODE FAILURE、TIMEOUT等)，但不能定位具體的故障位置和原因。

HPC上的大多數(shù)并行應(yīng)用程序需要很長時間來運行，它們的測試運行通常持續(xù)幾個小時甚至幾天，普通用戶不可能時刻查看程序狀態(tài)和節(jié)點狀態(tài)。如果程序運行失效后，普通用戶沒有第一時間發(fā)現(xiàn)程序運行結(jié)束，并且在發(fā)現(xiàn)運行結(jié)束后很難區(qū)分程序運行失效是由于程序自身bug還是節(jié)點的硬軟件故障，這將大大增加程序調(diào)試的時間和降低調(diào)試的效率。因此，需要一種基于Slurm的并行程序運行故障原因識別機制，通過監(jiān)控程序和節(jié)點狀態(tài)，當程序出錯時識別程序的故障原因。

2 并行程序運行故障原因識別系統(tǒng)

2.1 運行故障原因分類

HPC系統(tǒng)上并行程序運行失敗按照故障原因分類有多種維度。

1)按照故障現(xiàn)象分類(外在表現(xiàn))：有節(jié)點死機、程序異常退出、程序運行停滯、程序執(zhí)行時間異常和程序運行結(jié)果錯誤等類別。

2)按照故障原因分類：有程序編程錯誤和系統(tǒng)硬件/軟件故障兩種。

3)按故障的確定性分類：有確定性故障和非確定性故障兩種類別。確定性故障為每次運行都會出現(xiàn)的故障，具有確定性和可重復(fù)性；非確定性故障即在運行期間可能會出現(xiàn)的故障，具有不確定性。

把上述三種故障分類里2和3的故障類型進行組合，就可以得到以下四種故障類型：

a)編程錯誤導(dǎo)致的確定性故障；

b)系統(tǒng)硬/軟件失效導(dǎo)致的確定性故障；

c)編程錯誤導(dǎo)致的非確定性故障；

d)系統(tǒng)硬/軟件失效導(dǎo)致的非確定性故障。

本文的目標在于檢測出并行程序的運行故障，并將故障原因識別為上述4種故障類型，從而幫助程序員提高在HPC上運行和調(diào)試程序的效率。

確定性故障具有確定性和可重復(fù)性，當用戶程序在Slurm上運行出錯時，首先檢測錯誤原因是否為確定性故障。當程序運行出錯時，重新提交程序并且組合使用換節(jié)點不換程序、換程序不換節(jié)點等方法，檢測出錯原因是否為確定性故障。具體思路為：指定首輪節(jié)點，在首輪節(jié)點上運行另一種經(jīng)過驗證的程序，如果驗證程序出錯，可推斷為b；排除首輪節(jié)點，在其他節(jié)點上執(zhí)行該程序，在使用驗證程序確認新節(jié)點中無故障的情況下，如果該程序仍然出錯，則可推斷為a。

非確定性故障存在隨機性，且很難通過1～2次程序運行來復(fù)現(xiàn)和識別故障原因。通過采用在不同節(jié)點上多次重復(fù)執(zhí)行程序的方法，在運行次數(shù)比較多、得到足夠的運行結(jié)果后進行判斷。如果在多個節(jié)點上程序運行仍會出現(xiàn)故障，可推斷為c；如果在不同的節(jié)點上沒有出現(xiàn)故障，只在特定節(jié)點上出現(xiàn)故障，可推測為d。

2.2 系統(tǒng)架構(gòu)與實現(xiàn)

為了實現(xiàn)并行程序運行故障原因識別系統(tǒng)，本文在Slurm 19.05.2發(fā)行版的基礎(chǔ)上進行了擴展。擴展后的系統(tǒng)架構(gòu)如圖2所示，其中陰影填充的部分為擴展的模塊。

圖2 擴展后的Slurm架構(gòu)Fig.2 Extended Slurm architecture

為了進行故障現(xiàn)象的檢測和故障原因的識別，首先在Slurm的主控制進程slurmctld中擴展了故障檢測模塊和故障原因識別模塊，用于程序運行故障的檢測和故障原因的識別。

同時在Slurm中擴展了三個用戶命令，分別是mybatch、mytrigger和myrequeue命令。三個命令對應(yīng)功能如表1所示。

表1 實現(xiàn)的命令列表

基于在Slurm中實現(xiàn)的命令和模塊，并行程序故障原因識別的流程為：

步驟1：mybatch命令提交用戶程序，提交成功后返回作業(yè)編號。

步驟2：根據(jù)作業(yè)編號，故障檢測模塊對程序和程序所在運行節(jié)點進行狀態(tài)監(jiān)控。

步驟3：作業(yè)運行結(jié)束后，故障檢測模塊停止監(jiān)控，根據(jù)程序運行的結(jié)果進行下一步：如果程序運行結(jié)果為成功完成、取消、超出內(nèi)存限制、超過截止時間四種情況，根據(jù)運行結(jié)果可以知道運行結(jié)果的原因，結(jié)束故障檢測，轉(zhuǎn)到步驟5；如果程序是其他運行結(jié)果，轉(zhuǎn)到步驟4。

步驟4：如果程序重運行次數(shù)少于2次，將上輪節(jié)點加入程序的排除節(jié)點中，重新運行程序，同時指定上輪節(jié)點運行驗證程序，轉(zhuǎn)到步驟2；如果程序重運行次數(shù)大于或等于2次，轉(zhuǎn)到步驟5。

步驟5：故障原因識別模塊從作業(yè)數(shù)據(jù)庫中獲取用戶程序和驗證程序的多次運行結(jié)果，綜合兩種程序的運行結(jié)果，識別故障的類型。

2.3 故障檢測模塊

在用戶程序運行期間，為了及時檢測程序bug或系統(tǒng)硬軟件故障，需要對程序狀態(tài)和節(jié)點狀態(tài)進行監(jiān)控，因此在slurmctld中擴展了故障檢測模塊。故障檢測模塊的工作流程如圖3所示。

圖3 故障檢測流程Fig.3 Fault detection flow chart

在程序運行期間，每隔一段時間(預(yù)設(shè)15 s)根據(jù)用戶的程序編號檢查程序的狀態(tài)和程序所在節(jié)點的狀態(tài)。如果在程序運行期間某個節(jié)點通過心跳機制沒有響應(yīng)，那么該節(jié)點很可能出現(xiàn)了嚴重的硬件故障，導(dǎo)致了節(jié)點死機/崩潰，記錄該節(jié)點存在問題，并取消程序的運行。

當程序結(jié)束運行后，需要根據(jù)用戶程序的運行結(jié)果對程序進行處理。當程序運行結(jié)束后，記錄程序運行數(shù)據(jù)，并將運行數(shù)據(jù)發(fā)送到故障原因識別模塊。如果本次程序執(zhí)行是非正常結(jié)束(如失敗、超時、節(jié)點崩潰)，則把程序本次運行的節(jié)點集合加入該程序的排除節(jié)點列表，以使該程序在其他計算節(jié)點上重新運行。然后把該程序放到Slurm作業(yè)隊列中重新排隊，并且重新對該程序的狀態(tài)進行監(jiān)控。同時指定程序當次運行的節(jié)點集合運行驗證程序。驗證程序為預(yù)先選擇的且沒有編程故障的程序，驗證程序可以在系統(tǒng)中提前運行，那么運行驗證程序只需指定節(jié)點，然后將驗證程序重新排隊運行即可。

2.4 故障原因識別模塊

程序運行結(jié)束后，作業(yè)數(shù)據(jù)庫中的數(shù)據(jù)發(fā)送到故障原因識別模塊。使用An表示程序第n次運行的結(jié)果，Sn表示程序第n次運行時所在節(jié)點集合，Cn表示在Sn上運行驗證程序的結(jié)果，該模塊的故障原因識別流程為：

1)如果A1成功，則認為程序正常執(zhí)行；

2)如果A1失敗、C1失敗，則認為節(jié)點集合S1中發(fā)生了系統(tǒng)硬軟件故障導(dǎo)致的確定性故障；

3)如果A1失敗、C1成功，但A2失敗，說明S1正常工作。A2失敗后，還需對S2增加驗證程序的檢驗。如果C2成功，說明S2沒有故障，則認為用戶程序有bug，發(fā)生了由編程錯誤導(dǎo)致的確定性故障；如果C2失敗，說明節(jié)點集合S2中發(fā)生了系統(tǒng)硬軟件的確定性故障。

4)如果A1失敗、C1成功、A2成功，則認為存在非確定性的故障。但是非確定性故障的具體類型不確定，需要進一步識別。

進一步識別需要手動執(zhí)行myrequeue和mytrigger命令，重提交并監(jiān)控用戶程序，通過比較作業(yè)的運行結(jié)果和輸出結(jié)果，判斷作業(yè)是否出錯。如果出錯，則在節(jié)點上運行驗證程序，綜合在不同節(jié)點上程序和驗證程序的運行結(jié)果。如果在多個節(jié)點組合上程序運行出錯或者輸出結(jié)果不同，可推斷為用戶程序有bug；如果用戶程序在不同的節(jié)點組合上運行均成功，驗證程序也正常運行，可推測為S1中存在非確定性的硬件故障。

3 實驗測試

3.1 實驗環(huán)境與測試方法

實驗部署在4臺服務(wù)器(b1～b4)搭建的小規(guī)模機群中，其中b1是小規(guī)模機群的Slurm控制節(jié)點。機群中文件共享的軟件是網(wǎng)絡(luò)文件系統(tǒng)(network file system, NFS)，b3是NFS服務(wù)器。應(yīng)用程序采用高性能計算基準測試程序NPB[5]。由于實驗環(huán)境的限制，選擇NPB中的5個程序——IS、EP、LU、BT和SP，測試規(guī)模使用C級。表2列出了小規(guī)模測試集群的環(huán)境配置參數(shù)。

表2 測試環(huán)境配置

實驗主要分為兩個部分：準確性測試和運行開銷測試。其中準確性測試包括檢測準確率、識別準確率和識別延遲的測試；運行開銷測試主要針對系統(tǒng)對程序執(zhí)行的影響。

3.2 準確性測試

在實驗中，設(shè)置的評估指標為：

1)故障檢出次數(shù)(fault detection times, FDT)：故障注入后，故障檢測模塊成功檢測出來的次數(shù)；

2)故障識別次數(shù)(fault identification times, FIT)：注入的故障檢測出來后，故障原因識別模塊正確識別出故障原因的次數(shù)；

3)故障識別延遲：故障注入后，到故障原因識別模塊識別出故障原因所需要的時間。

針對程序自身bug導(dǎo)致的故障，在MPI并行程序源代碼中加入MPI_Recv阻塞死鎖、while無限循環(huán)、堆棧溢出等問題代碼。實驗中程序的最大運行時間為10 min。實驗結(jié)果如表3所示。通過實驗發(fā)現(xiàn)，死鎖和while無限循環(huán)等bug會導(dǎo)致程序運行超時，無限遞歸導(dǎo)致的堆棧溢出等錯誤會導(dǎo)致程序運行崩潰。程序自身的bug會導(dǎo)致程序在不同節(jié)點上的多次運行都失敗。從表3的實驗結(jié)果可以看出該系統(tǒng)可以有效地檢測和識別程序自身的bug。

表3 程序自身bug實驗結(jié)果

文獻[6]實現(xiàn)了HPC-SFI[6]，可以有效地在一個HPC系統(tǒng)中注入三種類型的系統(tǒng)故障，分別是節(jié)點內(nèi)故障、互連網(wǎng)絡(luò)故障和存儲/并行文件系統(tǒng)故障。本文使用HPC-SFI來隨機注入節(jié)點內(nèi)處理器故障、互連網(wǎng)絡(luò)故障和整個節(jié)點的故障。故障注入的實驗結(jié)果如表4所示。使用的測試程序是NPB的SP.C.2，驗證程序為BT.C.2，設(shè)置最大程序運行時間均為10 min。

表4 HPC-SFI硬件故障注入實驗結(jié)果

注入的互連網(wǎng)絡(luò)故障和整個節(jié)點的故障，會導(dǎo)致計算節(jié)點與控制節(jié)點之間的通信中斷，可以很快被故障檢測模塊發(fā)現(xiàn)；處理器故障導(dǎo)致作業(yè)運行時異常崩潰，作業(yè)運行提前結(jié)束。通過表4的實驗結(jié)果可以得出，本系統(tǒng)能夠100%檢測和識別HPC-SFI注入的硬件故障。

從表3和表4的平均識別延遲可以看出，故障原因識別延遲與故障類型存在一定的聯(lián)系。即在相同的測試程序下，平均故障延遲因故障的不同而不同。其中的原因是，故障檢測模塊需要至少運行2次用戶程序和一次驗證程序，同時在Slurm中重排隊的作業(yè)需要等待2 min才能再次被分配資源開始運行。所以當故障導(dǎo)致程序運行超時時，程序運行了最大運行時間后因Slurm超時機制而中止，平均識別延遲會較高；當故障導(dǎo)致作業(yè)運行崩潰或節(jié)點崩潰時，作業(yè)運行因故障提前中止，平均識別延遲較低。

潛在的故障是指一個故障在發(fā)生之前的潛在行為，潛在的故障是普遍存在的。許多節(jié)點故障不是突然變化的結(jié)果，而是長期性能下降(軟件老化)的結(jié)果。在潛在故障存在期間，節(jié)點的性能已經(jīng)出現(xiàn)了偏離，比如計算速度慢、計算出錯率高等問題，但節(jié)點尚未失敗。超過20%的機器故障都是由這些潛在的故障引起的[7]。

在實驗中分別模擬互連網(wǎng)絡(luò)丟包、CPU運行變慢等潛在硬件故障。在模擬潛在故障的實驗中，使用的實驗程序是NPB的SP.C.4，最大運行時間為10 min；驗證程序為BT.C.4，最大運行時間5 min。

通過Linux內(nèi)核的流量控制器Traffic Control對網(wǎng)卡發(fā)送的數(shù)據(jù)包進行限制，通過設(shè)置不同的丟包率模擬HPC系統(tǒng)中互連網(wǎng)絡(luò)的丟包、網(wǎng)絡(luò)中斷等故障。本文分別在丟包率為1%、5%和10%下運行了10次實驗。實驗結(jié)果如表5所示。

表5 網(wǎng)絡(luò)丟包故障實驗結(jié)果

本文使用開源工具cpulimit[8]限制用戶程序的某個進程的CPU使用率，從而模擬CPU速度異常變慢的故障。在程序運行后隨機選擇一個節(jié)點將SP程序的進程CPU使用率設(shè)置在90%、70%、50%，各運行了10次。實驗結(jié)果如表6所示。

表6 CPU故障實驗結(jié)果

在表5和表6的實驗中，總體的故障識別準確率是66.7%。通過模擬不同程度的潛在硬件故障，發(fā)現(xiàn)不同程度的潛在硬件故障對程序的影響結(jié)果不同。只有當故障嚴重程度超過一定程序時，導(dǎo)致作業(yè)運行超時，本系統(tǒng)才能探測出硬件故障。如果故障只是輕微或者瞬間發(fā)生的故障，系統(tǒng)很有可能探測不出來。

此外，在網(wǎng)絡(luò)丟包實驗中發(fā)現(xiàn)，設(shè)置的程序最大運行時間會影響故障識別的準確率。如果將實驗程序SP.C.4的最大運行時間設(shè)置為20 min，當丟包率為5%時，此時10次實驗程序的平均運行時間為15 min 43 s，程序均運行成功，將檢測不到故障。用戶對其程序的運行時間估計得越準確，并行程序故障原因識別系統(tǒng)的準確率越高。

3.3 運行開銷測試

在運行正常的情況下，對實驗使用的5個NPB基準程序分別運行20次，其中10次為在Slurm的sbatch命令進行提交，另外10次為在擴展后的Slurm中使用mybatch命令進行提交。當MPI并行進程數(shù)為2和4時，各基準程序的平均運行時間如圖4和圖5所示。

圖4 進程數(shù)為2時基準程序平均運行時間Fig.4 Average running time of benchmark program when the number of processes is 2

圖5 進程數(shù)為4時基準程序平均運行時間Fig.5 Average running time of benchmark program when the number of processes is 4

從圖4和圖5的實驗結(jié)果中可以看出，在程序不出現(xiàn)故障的情況下，系統(tǒng)運行開銷保持穩(wěn)定在-9.1%到3.8%之間變化，并且不會隨著基準程序的類型和進程數(shù)發(fā)生變化。這是因為在程序正常運行期間，故障檢測模塊主要開銷在于定時對作業(yè)狀態(tài)和節(jié)點狀態(tài)進行輪詢。輪詢主要依靠slurmctld和slurmd之間的通信，不會影響作業(yè)在計算節(jié)點上的運行。這意味著并行程序故障原因識別系統(tǒng)的開銷很小，不被程序類型和程序運行規(guī)模所影響，擴展性好。

4 相關(guān)工作

雖然已經(jīng)開發(fā)了許多方法和工具，但調(diào)試大型并行程序仍然是一個艱巨的問題。交互性調(diào)試(例如TotalView[9]、Arm DDT[10])是一種傳統(tǒng)方法，通過允許在一個窗口中的許多進程和線程同時進行調(diào)試，可以在一個單獨的線程內(nèi)或任意進程或線程的組合內(nèi)對代碼逐行執(zhí)行運行、步進和終止，來完成對程序執(zhí)行的完全控制。但是這種方法不能自動檢測程序故障。此外，在運行大規(guī)模程序時，人工分析數(shù)以萬計的進程數(shù)據(jù)耗時耗力。一些調(diào)試工具在執(zhí)行期間收集各種程序狀態(tài)，并將其提供給程序員以進行后期分析。例如，堆棧跟蹤分析工具(STAT[11])從并行程序的所有進程中收集堆棧跟蹤。通過這些跟蹤，程序員可以生成調(diào)用圖前綴樹，以前綴樹的形式匯編應(yīng)用程序的行為。但是，STAT不適合普通用戶進行調(diào)試，因為STAT依賴于許多軟件，這些軟件需要系統(tǒng)管理員預(yù)先安裝并且超出普通用戶的權(quán)限；STAT無法自動識別程序故障，需要人工干預(yù)，調(diào)試運行時間較長；STAT沒有考慮程序調(diào)試期間硬件故障的影響，因此無法在發(fā)生故障時區(qū)分硬件/軟件故障和程序錯誤。

為了簡化大規(guī)模執(zhí)行下并行程序確定性重放的復(fù)雜性，Guo等[12]設(shè)計實現(xiàn)了一種使用兩個節(jié)點重新運行大規(guī)模MPI并行程序的系統(tǒng)，大大減少了重放所需的節(jié)點數(shù)。并行程序的一個進程在計算節(jié)點上運行時，需要與其他進程通信，但是它與之通信的進程可能沒有在運行。為了建立一個使重新運行的進程正常執(zhí)行的環(huán)境，需要在計算節(jié)點上模擬MPI通信環(huán)境，這需要比較長的時間來完成。Zhai等[13]根據(jù)并行程序中許多進程具有相似的計算模式這一特點，首先使用層次聚類方法對運行程序的進程進行聚類，然后從每個進程聚簇中選擇一個具有代表性的進程進行重放。這種“代表性”重放的方法減少了重放的進程數(shù)量，從而顯著減少重放所需的時間。但是這種方法只能用來預(yù)測HPC的性能，不能用于故障檢測。同時他們的方法都忽略了大規(guī)模并行程序調(diào)試中硬件故障的影響。本文方法可以自動識別程序故障，并進一步區(qū)分硬件故障和程序錯誤故障，以進行更好的調(diào)試。

目前針對高性能計算系統(tǒng)故障的研究熱點是基于系統(tǒng)日志和傳感器數(shù)據(jù)的軟件/硬件故障檢測?；谔厥忸I(lǐng)域的高性能計算機群運行的作業(yè)具有相對穩(wěn)定的運行行為，Wu等[14]提出了一種基于異?；顒臃治龅母咝阅芟到y(tǒng)運行時失效檢測方法，但這種方法只能針對具體領(lǐng)域內(nèi)的重復(fù)性作業(yè)，具有很強的局限性；Gabel等[7]相同的時間下在多臺配置相同的機器上執(zhí)行相同的任務(wù)，通過傳感器獲取機器的運行性能，如果一臺機器的性能與其他機器顯著不同，就會被標記為可疑，即懷疑該節(jié)點存在潛在故障；Ghiasvand等[15]定時采集系統(tǒng)日志，得到系統(tǒng)日志生成頻率，如果某個節(jié)點日志生成頻率與大多數(shù)節(jié)點的偏差超過一定閾值，則認為該節(jié)點出現(xiàn)了故障。由于傳感器數(shù)據(jù)與系統(tǒng)日志有固定的格式和規(guī)律，是可以根據(jù)關(guān)聯(lián)規(guī)則進行挖掘的文本，因此機器學(xué)習(xí)也是用于高性能計算機群故障探測主要方法之一[16-17]。但是很多時候作業(yè)在HPC上運行時，運行速度與用戶預(yù)期相差較大；同時因為很多作業(yè)是首次提交，沒有作業(yè)運行的數(shù)據(jù)記錄，不能依靠系統(tǒng)日志和傳感器數(shù)據(jù)來檢測故障。本文的系統(tǒng)不依賴于系統(tǒng)日志和傳感器數(shù)據(jù)，根據(jù)用戶程序與驗證程序的運行結(jié)果可以區(qū)分程序運行錯誤與節(jié)點的硬軟件故障。

5 結(jié)論

并行程序自身存在的編程bug會導(dǎo)致程序運行出錯，另外，高性能計算系統(tǒng)硬軟件故障概率的增加導(dǎo)致并行程序在運行時出錯的概率隨之增加。本文從普通權(quán)限的編程人員/用戶角度，提出一種在HPC上程序調(diào)試失效時識別故障原因的思路。通過對作業(yè)管理系統(tǒng)Slurm進行擴展，監(jiān)控作業(yè)和節(jié)點狀態(tài)，指定節(jié)點和排除節(jié)點重提交程序。根據(jù)程序多次運行結(jié)果，識別故障原因的類別，從而提高程序員在HPC上識別編程錯誤或系統(tǒng)硬軟件故障的效率。實驗表明，該系統(tǒng)具有較低的開銷和較高的準確率。