神威超級計算機運行時故障定位方法

高劍剛 鄭 巖 于 康 彭達佳 李宏亮 劉 勇 何王全 陳德訓 王 飛

1 （國家并行計算機工程技術研究中心 北京 100190）

2 （江南計算技術研究所 江蘇無錫 214083）

（13701512205@139.com）

超級計算機是解決經濟建設、社會發展、科學進步、國家安全等一系列重大挑戰性問題的重要手段，已經成為信息時代世界各大國綜合實力的體現.目前，超級計算機的峰值速度已經達到E 量級規模，根據2022 年5 月發布的Top500[1]，排名第一的超級計算機是部署在美國能源部下屬橡樹嶺國家實驗室的超級計算機前線（frontier），其峰值性能為1.686 EFLOPS，實測Linpack 性能為1.102 EFLOPS，峰值計算能力為537 PFLOPS，Linpack 持續性能為442.01PFLOPS.中國的“神威太湖之光”超級計算機排名第六，峰值性能為125 PFLOPS，持續性能為93 PFLOPS. 綜合分析以往Top500 榜單，超級計算機的性能發展趨勢是約每4 年提高1 個數量級，略高于摩爾定律.

隨著高性能計算機的規模越來越大，系統的可靠性也面臨巨大挑戰. 通過分析超級計算機Blue Waters[2]的500 萬份高性能計算（high performance computing,HPC）作業，可以發現作業規模從 10 000 個節點增加到22 000 個節點，故障概率也會從 0.8% 增加到 16.2%，并且一旦節點發生故障，它很可能會衍生后續故障.IBM Blue Gene/L 包含1 024 個計算節點，峰值性能70.72 TFLOPS 的平均無故障時間（mean time between failure, MTBF）為53 158 h[3-4]. 超級計算機CRAY XT4[5]包含23 016 個處理器，峰值性能為101.7 TFLOPS，MTBF大約為772 h；超級計算機泰坦（Titan）有 18 688 個節點，每個節點有一個 AMD 16 核Opteron CPU（整個系統有 299 008 個內核）、一個 NVIDIA Tesla K20 GPU和 32 GB 的主內存，MTBF 大約為100 h[6]. 可以看出，隨著超級計算機運算核心規模的增大，平均無故障時間也越來越短，這要求系統提高故障定位的效率.

現代超級計算機組裝了大量的處理器、加速器、內存模塊和更多部件，比如處理器計算核心的規模，在過去10 年內從十萬量級迅速上升為千萬量級，高效故障定位分析對系統的可靠性越發重要，但也變得愈發困難[7-8]. 目前的故障定位技術需要對海量信息進行采集和分析，包括計算資源、I/O 部件、網絡環境以及操作系統等，并且多種故障之間具備很強的關聯性，在大規模的并行環境下存在傳遞效應，某個根源性的故障可能引起多個故障的發生，例如表征為通信錯誤的課題，實則為某節點故障無法正常吞吐消息，采用重發并不能解除故障，采用回卷、遷移等操作則需要能定位錯誤節點. 如果通過并行故障定位工具來定位系統問題[9-10]，往往對明顯的硬件故障有較好的效果，但對于軟件掛起問題或者瞬時的系統異常，定位的精確度和效率都存在一定局限性.

當系統處理器、網絡、存儲器等硬件系統發生故障時，操作系統和維護系統可以通過定期探測、心跳檢測、日志分析等手段來定位故障發生的原因，但很多系統的異常并不會通知操作系統或管理軟件，也不會在日志系統中記錄，比如結果錯、單錯、網絡丟包等信息，但往往關聯性的錯誤會對系統造成巨大影響. Titan 是位于橡樹嶺領導計算設施 （oak ridge leadership computing facility，OLCF） 的 Cray XK7 系統，是最早使用CPU 和GPU 混合架構的超級計算機之一. Titan 的峰值性能為 17.59 PFLOPS，當它退役時，它在 Top500 排名中排名第九[11]. Titan 上的每個異常事件都會自動注冊到故障數據庫中. 據統計，Titan 在2014—2018 年5 年的故障事件總數為2 663 512. 經過一個過濾階段，故障數據庫中的事件數量減少了99.78%. 剩下的 0.22% 的事件對應于我們所描述的5 654個獨特的故障，分別分布為 565，649，1 824，1 291，1 325個事件. 雖然Titan 系統通過篩選丟棄相關衍生故障，提高了錯誤定位精度，但通過單一的探測方法，依然無法對大規模并行計算系統高效地錯誤定位.

在程序運行出錯時，從用戶視圖看會有輸出結果錯誤、輸出報錯和長時間無輸出3 種直觀表現，其中輸出結果錯誤是指輸出沒有達到預期，用戶需要通過分析軟件代碼結合調試工具確定錯誤原因，這種錯誤只能由具備預期的用戶去發現和定位；輸出報錯通常是用戶程序或者運行環境捕獲到運行時錯誤，將錯誤現象甚至原因反饋給用戶，進而采取相應的錯誤處理措施和軟硬件故障修復；而對用戶來說，長時間無輸出是程序運行時最難以發現和定位錯誤的情況，由于沒有反饋無法判斷程序當前是否運行正常，只能求助于系統管理員進行調試和維護檢查.

在并行計算機系統中，運行時系統是指程序執行時支持其解釋、運行、檢查、調試、優化等功能的系統運行環境，運行時環境是拉近用戶程序和系統平臺之間鴻溝的一個重要層面，讓程序運行在更好的運行時環境下能夠更好地發揮出應用程序的性能，減少運行時間從而增加系統效率[12]. 目前在超級計算機系統設計中，系統管理服務、操作系統、并行語言庫等支撐程序運行的環境都可以稱為運行時環境.

本文的主要貢獻是針對程序掛死和無直接硬件異常的大規模應用，提出了一種用戶層運行時故障定位方法，在不依賴系統管理服務的情況下，利用應用程序本身的并行特性，快速對軟硬件異常進行篩查和定位，以適應超級計算機的好用性和可擴展性需求；該方法不僅針對特定故障類型，而且可以全面地對程序掛死、文件讀寫問題、硬件異常進行篩查，提高了故障定位的效率，豐富和完善了面向超大規模并行計算機系統錯誤定位的技術手段.

1 相關工作

在高性能計算中，故障定位用于在大規模并行程序中找到異常的原因，是系統維護和軟件開發周期中最關鍵和最耗時的過程之一，其中基于運行時的故障定位方法也被廣泛使用.

循環感知進度依賴分析工具 prodometer[13]用于高性能計算故障定位和大規模并行應用程序調試.prodometer 需要在MPI（message passing interface）程序中預先鏈接一個函數庫，并在運行過程中為每個進程建立馬爾可夫模型，用于分析軟件棧的依賴關系.通過推斷MPI 任務循環內的進度依賴性，可以顯著減少識別故障起源任務的工作量，找到系統中進展最少的任務，從而精確地定位出現故障的MPI 進程.prodometer 應用在 IBM Blue Gene/Q 高性能計算機上，成功定位了32 768 個任務中的故障原因.

天河二號超級計算機上的故障原因解析器[14]通過使用分布式監視器觀察異常消息傳遞行為來檢測程序故障，并利用事件驅動機制同時觸發不同節點組之間的全局狀態檢查. 實驗結果表明，故障原因解析器用于故障檢測的延遲是可以接受的，開銷可以忽略不計. 此外，該技術不需要管理權限，可以很容易地集成到現有的大型并行程序中.

基于故障定位樹的檢測框架MPFL（messagepassing based on fault localization）是一種基于消息傳遞的故障定位方法[15]，采用層次化和分布式的設計思想，將全局的故障定位任務分配給不同的節點，由各節點運行輕量級的故障定位進程，對局部范圍內的多個節點進行故障的檢測和分析.

Bolt[16]利用運行時檢查來檢測軟錯誤，并提出了一種編譯器指導的軟恢復方案，該方案提供細粒度和有保證的恢復，而不會產生過多的性能和硬件開銷.RedMPI[17]專注于檢測和糾正 MPI 應用程序中的靜默數據損壞，其中應用程序數據的損壞通過在副本之間產生不同的 MPI 消息來表現出來.

文獻[13-17]所述的方法雖然通過分布式并行和C 運行時方法提高了故障定位效率，但依然存在依賴消息通信和錯誤定位方法單一的問題.

2 面向神威超級計算機的運行時故障定位方法

2.1 運行時故障定位架構設計

在超級計算機的運行過程中，由于硬件故障和軟件錯誤的表現特性并不一樣，定位的方法和手段也有著很大的不同. 通過建立面向高性能計算的多策略協同的并行錯誤定位架構，可以快速對超大規模并行計算機系統進行錯誤溯源分析與處理，以實現系統故障的快速發現、分析、隔離與處理，支撐超級計算機容錯和高可用需求，提高系統可用性.

本文面向新一代神威超級計算機，提出了運行時故障定位方法，針對程序出錯時無硬件異常現象和操作系統日志信息問題，利用基于運行時庫的錯誤探測分析、基于全局聚合信息的綜合診斷、面向申威眾核處理器的異常線程過濾等錯誤定位技術，同時進行軟硬件異常處理，構建了基于用戶層的軟件探測分析的高效錯誤定位方法，并行運行時故障定位架構如圖1 所示.

Fig.1 Parallel runtime fault location architecture圖1 并行運行時故障定位架構

1） 基于運行時庫的錯誤探測分析技術

神威高性能網絡接口芯片（Sunway high-performance network interface chip，SWHNI）采用硬件方式負責網絡層傳輸，實現了處理器間高速通信，層功能實現了為計算機系統提供高帶寬、低延遲的數據傳輸能力[18].

基于運行時庫的錯誤探測分析技術通過網絡接口芯片SWHNI、神威消息庫及網絡管理軟件，可以對大規模系統的局部資源錯誤進行快速定位，通過緊密耦合節點間消息實現機制，感知運行時錯誤并進行分析和定位，快速準確發現錯誤源頭.

2） 基于全局聚合信息的綜合診斷技術

SWHNI 消息引擎實現了軟件定義的硬件集合通信機制，解決了超級計算機中受限的硬件資源和巨大的軟件需求間的矛盾，大幅度提高了集合通信的處理能力、可擴展性和實用性，為全局聚合信息的分析提供了支撐[18].

基于全局聚合信息的綜合診斷通過硬件集合通信機制，可以實時開展全局計算與通信資源的狀態診斷，針對大規模并行應用常見的面向全局資源調試難、診斷難的問題，通過在線狀態收集和離線分析相結合的方法，實現錯誤狀態的快速、準確診斷.

3） 面向申威眾核處理器的異常線程過濾技術

神威超級計算機的維護處理機系統（baseboard management controller，BMC）為插件上的眾核處理器提供基礎維護及數據采集服務，由于插件上的處理器數量有限，全機的BMC 系統可以進行并行狀態檢測[19].

面向申威眾核處理器的異常線程過濾技術基于BMC 系統，可以高效排查眾核處理器的異常狀態，可精準定位部分大規模并行應用程序因硬件失效、應用程序錯誤而導致的無現象異常掛死、消息死鎖、集合操作掛死和I/O 故障問題等，提高了并行程序調試的效率和好用性.

神威超級計算機運行過程中，軟硬件的錯誤都可能導致系統發生掛死，最常見的問題往往出現在處理器單元、消息部件和全局共享系統3 個運行時故障定位技術中. 這3 個技術都具有運行時特性，通過技術融合，可以在不影響用戶課題運行的情況下，基本覆蓋常見的軟硬件錯誤，診斷出錯誤的源頭.

通過綜合上述3 個故障定位技術，設計一體化的并行時故障定位技術，為超級計算機系統錯誤定位提供了有力的技術支撐.

2.2 基于運行時庫的錯誤探測分析

在高性能計算機中，應用級錯誤主要來自于操作系統的異常報告、網絡管理的消息超時、作業管理的節點錯誤和狀態查詢中斷，神威超級計算機中使用的運行時庫主要包括通信庫（MPI 庫）和并行語言庫，其提供的異常查詢接口對并行應用運行過程中報告的錯誤進行定位，為上層并行語言提供錯誤定位支持，具體的軟件棧如圖2 所示.

Fig.2 Error detection analysis based on the runtime library圖2 基于運行時庫的錯誤探測分析

錯誤檢測主要是通過基于定制的消息探測和關聯故障綜合分析相結合的方式進行，其中定制消息探測包括響應探測、狀態探測和投票探測3 種方法.

1） 響應探測

要求目標節點立即返回響應消息，以判別該目標節點與發起節點的網絡是否連通. 發起節點可以向周圍節點群發送響應探測check_ping消息，收到該消息的節點需要立即回復無數據的應答消息reply_ping，以幫助發起節點判斷自身的通信環境.

2）狀態探測

要求目標節點返回節點資源狀態、通信狀態或者消息日志內容等運行狀態信息. 如圖3 所示，節點P1向目標節點P2發送狀態探測消息check_status，P2根據收到的消息內容回復P1包含對應信息的reply_status消息. 狀態探測應用在多種場景中，例如P1等待接收P2消息超時，可以通過狀態探測取得P2的消息日志，分析它是否已發送相關消息、當前處于什么消息狀態等；在同步超時的情況中，同步發起節點可以主動探測未同步節點在該進程組內最近同步操作的狀態. 狀態探測消息可以根據具體的問題進行擴展，使得發起節點能夠得到分析錯誤所需要的各種信息.

Fig.3 Message-based error detection method圖3 基于消息的錯誤探測方法

3）投票探測

發起節點要求節點組內所有節點都對目標節點進行響應探測或狀態探測，并匯報結果進行投票. 如圖3 所示，節點P1向目標節點P2所在進程組內所有節點發起投票探測消息check_vote；收到該消息的節點需要立即向P1回復reply_vote消息告知P1通信正常；同時向P2發送響應探測消息check_ping，收到回復或超時后向P1發送對P2運行狀態的投票消息reply_vote，以幫助P1確認P2的運行狀態.

運行時系統在初始化時為每個節點指定拓撲相關的錯誤檢測負責節點，以保證探測的效率. 錯誤被定義為五元組〈src,dst,time,type,status〉，其中src為發現錯誤的節點，dst為發生錯誤的節點，time為對應發現錯誤的時間，type為內部定義的錯誤類型，status為存儲當前探測進度. 定位流程包括：

1） 節點src感知到錯誤后，將立即向dst發起響應探測，并向dst對應的負責節點Pr報告探測結果；

2） 負責節點執行錯誤分析，Pr查詢消息日志，通過time判斷是否在一定時間內包含對dst的探測記錄；

3） 檢測type屬性，對于已完成相同探測的等待status標記完成后返回，通過排重和關聯合并錯誤，不能合并的則執行新增錯誤操作；

4） 對于新增錯誤發送消息進行探測；

5）Pr綜合報錯結果，進行錯誤分析并報告.

錯誤檢測模塊將錯誤定位任務與底層消息機制緊密聯系起來，能夠更好地適應高性能計算系統. 通過修改并行語言運行時庫（MPI 庫的消息實現），在消息日志中記錄每個正常消息發起時間并設置計時器，計時器超時將觸發錯誤分析模塊（在3.2 節的測試中將討論由此帶來的額外開銷）. 計時器的時間閾值由消息類型和通信距離共同決定，經過排重和關聯后，依據規則庫決定消息探測的類型. 響應探測通常針對2 點之間的1 對1 消息超時，狀態探測是在確定對方存在響應后的進一步狀態獲取，投票探測則是在關聯發現多對1 故障后的探測手段. 錯誤探測分析對用戶透明，僅在發現疑似問題后向用戶通知錯誤信息. 錯誤探測的開銷包括消息發起開銷和消息響應開銷2 個部分，我們通過限制探測消息的長度，即將狀態探測的數據控制在單包短消息數據長度內，以保證探測流程盡量不影響系統的正常運行，在神威系統中單包消息延遲為微秒級；消息響應時間與探測觸發時機、應用類型緊密相關，視被探測方何時查看消息隊列而定. 通常來說，計算密集型課題消息處理間隔時間較長，而消息密集型課題會更頻繁地去主動獲取網絡消息，對消息的響應時間更短，因此更適合錯誤探測的方法，在實際應用中錯誤探測和分析的總時間可以控制在秒級.

錯誤分析模塊包含通過歷史查錯經驗總結的規則庫，指定滿足錯誤合并的條件，例如其中有些重復的案例：

1） 多個節點報與同一節點消息超時或掛死；

2） 多個同步操作報掛死在同一節點；

3） 多個消息死鎖在同一資源；

4） 短時間內節點上多次I/O 錯誤；

5） 接收其他軟件提交的錯誤信息等.

也有部分可以進行關聯的案例，例如：

1） 網絡錯誤，導致消息或同步掛死；

2） 節點硬件故障，導致其他節點報消息超時或掛死；

3） 節點硬件故障，導致同步掛死；

4） I/O 錯誤導致消息超時或掛死.

在錯誤分析模塊中，對錯誤檢測發現的錯誤信息進行關聯，通過匹配錯誤類型、錯誤位置、錯誤時間區域進行快速篩選去重，從而快速定位錯誤根源.

基于運行時庫的錯誤探測方法是對用戶透明的，通過局部多進程消息的方式進行探測，在代價較小的前提下能夠較為準確地發現節點狀態、消息部件故障以及部分軟件問題引起的錯誤，通過進一步的排重和關聯，能夠有效避免錯誤報告雜亂無效的問題.

2.3 基于全局聚合信息的綜合診斷技術

在大規模并行程序運行過程中，由于任務分配不均勻造成的部分節點暫時無輸出，與節點、網絡故障等硬件錯誤或者軟件編寫錯誤造成的程序掛死（程序在某一操作中等待觸發條件以結束該操作，然而觸發條件無法達到）現象，對用戶來說難以準確分辨. 然而，由于系統規模巨大，特別是在無輸出的條件下，用戶難以快速判斷是否有錯誤發生，以及進一步分析得到錯誤原因，因此為提供用戶發起的運行時程序狀態檢查機制十分必要.

當前常用的檢查方法包括窮盡排查和在線調試等. 窮盡排查是指系統管理員通過維護管理工具依次排查系統硬件和運行環境狀態，查找是否有可能影響當前任務運行的故障出現，從而推斷出當前程序無輸出是否處于不正常狀態，這種方法由于不具有針對性的查找，工作量大且最后結果并不能排除程序本身錯誤，因而存在不確定性，不適合大規模系統和應用. 在線調試是使用更多的一種方法，用戶或者程序開發維護人員通過調試工具對計算系統中的單個節點依次進行重現式檢查，查看節點是否陷入死循環等狀態；更進一步的方法是開發人員在程序開發時記錄程序運行狀態，維護人員通過在線調試工具依次檢查該狀態以判斷程序是否運行正常. 然而，在大規模環境下由于節點較多，用戶不具備全局視圖，并且部分運行時的實現對用戶是透明的，依次檢查耗時可能十分漫長，而且在調試過程中也可能改變程序運行狀態.

在神威超級計算機軟件系統中，通過在運行時庫中加入接收用戶信號的接口，由對程序運行狀態最關心的用戶發起檢查，將部分節點作為葉子節點，采用遞進的樹型結構層層推進檢查流程，最終向用戶報告當前程序運行狀態. 該技術在不影響程序運行狀態的前提下，幫助程序運行用戶了解當前程序運行狀態，既能夠避免程序運行用戶由于等待時間太長而“殺掉”程序的誤操作，又有助于實際發生錯誤時的進一步處理. 該技術由用戶發起，減輕了系統維護人員的負擔，利用節點之間的消息通信機制，對程序運行狀態進行收集和比對，有針對性地得到程序運行狀態，能夠及時發現程序運行錯誤.

在并行程序中，進程最終都需要通過集合消息實現一致性協調，當部分節點在計算過程中發生軟硬件故障時將無法到達集合點，或者在集合過程中發生通信故障，都會導致程序掛死. 基于全局聚合信息的綜合診斷，分為在線收集和離線診斷2 個階段.

在線收集階段負責一次性獲取全局所有節點的軟硬件狀態信息，主要有4 個步驟，如圖4 所示.

Fig.4 Online collection of global status圖4 全局狀態在線收集

1）發起診斷. 用戶向指定作業發起診斷，并準備好狀態數據輸出文件.

2）診斷類型分析. 判斷是否處于集合消息過程中，以及是否處于點對點消息等待狀態.

3）數據狀態收集. 收集節點狀態信息，即進程通過共享內存和消息通信聚合狀態信息. 收集數據采用分區聚合的方法，由于部分節點或者通路故障導致的收集錯誤，將觸發軟件超時并報告，將對應的數據置為空.

4）狀態輸出. 全局主節點收集數據后進行分類和預處理，輸出到對應文件.

離線診斷分為5 個步驟，如圖5 所示.

Fig.5 Comprehensive diagnostic technique based on global aggregation information圖5 基于全局聚合信息的綜合診斷技術

1） 數據合并. 將狀態文件批量合并處理，并按照進程編號進行排序.

2） 快速分類. 對狀態進行預分析，分別存儲不同通信域的集合狀態數據.

3） 數據總量校驗. 檢查是否有無狀態進程，判斷是否有節點down或進程被殺死.

4）集合狀態匹配. 根據集合狀態，區分進程當前所在的通信域，檢查是否有未到達進程；對未到達節點進行關聯分析，檢查不同通信域之間是否存在依賴關聯.

5） 硬件狀態掃描. 當軟件狀態顯示無未到達進程時，使用深度優先算法掃描集合樹中進程的硬件狀態，判斷是否存在網絡硬件錯誤；對于集合狀態匹配發現的未到達進程，同樣需要掃描該進程的硬件，判斷是否存在錯誤.

基于全局聚合信息的綜合診斷技術在運行時使用消息聚合的方法收集各節點狀態信息，與運行時錯誤探測分析技術在觸發機制、實現方法以及目標問題類型上都有所不同. 在觸發機制上，運行時錯誤探測分析技術由消息計時器超時觸發、對用戶透明，基于全局聚合信息的綜合診斷技術由用戶判斷，課題長時間無輸出后主動發起. 在實現方法上，前者是完全基于運行時消息的探測方式，存在探測—分析—探測的迭代定位模式；后者使用消息僅是作為一次性收集信息的手段. 在問題類型上，前者主要針對局部問題，消息內容超過單包后將報警；后者的分析樣本數據更大，因此采用離線分析的方式，更適合于較大規模系統的綜合分析.

相較于窮盡排查的方法，本節所描述的技術能夠獲取程序本身的運行時信息，包括但不限于當前的通信對象和類型、計算的操作類型和位置等，因此更具有針對性. 這些信息可以反映運行節點之間當前聯系狀態，因此需要通過樹型結構進行聚合，通過統一視角進行離線分析. 本文技術也可以作為在線調試的前置，在確定問題節點或者代碼范圍的基礎上，通過在線調試手段進行更精確診斷.

2.4 面向申威眾核處理器的異常線程過濾方法

在申威眾核處理器中，所有線程的程序計數器可以被有效用于定位并行程序中異常掛起的線程.當程序出現掛起異常時，一種比較常見的現象是：少量線程執行到某個同步或者通信語句時，由于硬件故障或編碼錯誤，不滿足條件停止執行，進入等待狀態. 此時，其PC（program counter） 值是穩定不變的；而其他絕大部分線程能夠正常執行一段時間，直到出現同步或通信等待，此時，它們的PC 值要么不斷變化，要么不變，但其值與異常線程的PC 值通常不同.在這種情況下，我們可以數次采集所有線程的PC，找出那些PC 值一直不變的線程，并根據PC 值不變量將線程分為不同的類，通常我們可以將所有線程分為少數幾類，然后將這些類展示給用戶，輔助定位異常進程、線程. 在明確異常進程、線程的情況下，根據PC 值能夠直接定位到錯誤程序掛住的代碼行，有效提高了程序調試效率.

異常線程過濾方法的具體流程為3 步：1）數次采集目標程序所有線程的程序計數器；2）過濾出PC 值在多次采樣中均為改變的線程；3）根據PC 值，將異常線程分組. 對于掛起的異常線程，若其PC 值不變，算法能夠檢測到并記錄.

對于進入等待狀態的正常線程，通常數量較多，可以通過數量與異常線程區分開來；對于仍在執行的正常線程，PC 值變化且2 次采集通常不同，將不會記錄.

該方法的處理時間主要由步驟3）的異常線程分組構成，即對每一個線程，根據其PC 值查找對應的分組，并將其插入分組. 因此，處理時間與線程的數量和不變程序計數器的類數相關. 假設作業中的線程數為n，不變程序計數器的類數為M，則方法的時間復雜度為O（M×n）.

增加采樣次數，能夠有效提升方法的準確性. 程序執行中存在一種情況：正執行一個很大迭代次數的循環線程，多次PC 掃描的值相同，這將導致誤判.假設某個線程在執行一個k條指令的循環，為了簡化分析，我們假設采樣PC 值時線程正在執行每條指令的概率相同（采集的時機是不確定的，可視為隨機，但實際上，不同的指令需要不同的周期數，采集到某指令PC 值的概率還與指令執行周期數有關），概率為1/k，則s次采樣PC 值均相同的概率為

對于n個獨立的線程來說，s次采樣PC 值均相同的線程數的期望為

為了過濾這些正常執行的線程，增加采集次數，使得期望E＜1，此時

假設程序中n=1×107,k=250，我們可以采集至少4（s＞3.91）次，保證每次采集PC 值均相同的正常執行的線程數的期望小于1.由式（3）可見，k值越高，意味著需要采集的次數s越小；相反地，一個較低的k值意味著循環執行時間越短，在數次采樣中，線程執行的程序塊通常不同，也意味著PC 值不同. 在實際應用中，程序循環塊的指令條數往往較高，即k＞250，因此僅需進行3 或4 次采集即可. 上述分析是統計學上的期望，實際應用中仍然存在在數次采集中PC 值均相同的線程概率，但由于判定出錯的線程數量極少，用戶使用調試跟蹤等手段可以輕易排除這類錯誤.

在采集的過程中，獲取到的運算控制核心的PC值可能指向其他進程或者操作系統核心代碼. 這種情況下，如果運算處理核心在執行加速核，那么其對應的運算控制核心在等待所有運算處理核心結束運算，其狀態是確定的. 一般情況下，高性能計算應用占用了絕大部分CPU 時間，BMC 采集到的PC 值大概率屬于目標的計算進程. 如果在多次采樣中，采集到的運算控制核心的PC 值均不屬于目標進程，那么這個進程很有可能發生異常.

該方法能夠精確定位大規模并行應用程序因硬件失效、應用程序錯誤而導致的無現象異常掛死、消息死鎖、集合操作掛死和I/O 故障問題. 對于部分程序錯誤導致線程PC 值持續不斷變化的錯誤，該方法存在一定局限性.

3 實驗結果與分析

3.1 實驗平臺

本文采用的實驗平臺是新一代神威超級計算機，該機器采用SW26010-Pro 眾核處理器，處理器架構與“神威·太湖之光”系統的SW26010 處理器[20]架構類似，每個處理器包含6 個核組，每個核組中有65 個核心，總共390 個核. 每個核組包含一個管理處理元素、一個計算處理元素集群和一個內存控制器，核組中運算核心以8×8 陣列方式進行排布，運算核心之間以及運算核心與外部交互通過陣列內網絡進行互連.SW26010-Pro 處理器支持大量線程和數據并行性，在并行工作負載上提供高性能，SW26010-Pro 處理器的架構如圖6 所示.

Fig.6 Architecture of SW26010-Pro many-core processor圖6 SW26010-Pro 眾核處理器架構

實驗最大使用總共32 768 個SW26010-Pro 眾核處理器，具備12 779 520 核并行規模.

3.2 基于運行時庫的錯誤探測分析

基于運行時庫的錯誤探測分析需要通過消息庫的探測和分析，在不影響用戶程序的同時，不斷對系統錯誤進行迭代分析. 由于該技術需要在系統運行時庫核心中增加錯誤定位與分析模塊，并對用戶發起的探測行為進行響應處理，記錄與分析消息日志、節點狀態等信息，會對課題運行帶來一定的開銷. 信息記錄的動作由消息和定位觸發，因此開銷也和通信密度成正比，相對來說，通信密集型課題開銷會比計算密集型課題開銷更大.

我們使用NAS 并行基準（NAS parallel benchmark,NPB）測試程序集（版本3.3.1）標準測試程序，包含IS，FT，EP，CG，LU，MG，BT，SP 等程序，在這些程序中都包含常用的通信操作. 我們設置問題規模為E 規模，在NPB 測試程序中E 規模下不支持IS，因此在本實驗中忽略該程序.

在4 096 進程規模下測試關閉和開啟錯誤探測分析帶來的時間開銷百分比為

其中t_fl為開啟錯誤探測分析后的運行時間，t_ori為測試程序在原始環境下的運行時間，測試結果如表1 所示.

Table 1 Percentage of NPB3.3.1 Assembly Time Overhead表1 NPB3.3.1 程序集時間開銷百分比

測試課題額外增加的時間開銷百分比最大為1.39%，最小僅為0.38%，結果表明，基于運行時庫的錯誤探測分析方法對程序本身的運行幾乎不會產生影響.

3.3 基于全局聚合信息的綜合診斷

基于全局聚合信息的綜合診斷過程分為在線和離線2 個階段，在線數據信息收集階段的時間開銷同課題運行進程規模、節點的拓撲結構相關，離線分析階段的時間開銷與終端處理狀態文件的性能和錯誤類型相關. 由于該方法可以不影響程序運行狀態的前提下幫助程序運行用戶了解當前程序運行狀態，并且采用離線分析系統規模較大時可能存在可擴展性問題. 為測試診斷方法的可擴展性，在新一代神威超級計算機中，將一個已知故障節點放入測試環境作為錯誤類型樣本，測試題在做集合操作時故障節點會導致課題掛死. 在此模擬錯誤環境下，測試不同進程規模的錯誤定位總時間，每次測試取10 次平均值，系統規模為4～32 768 節點，其中每個節點上運行6 個進程，結果如圖7 所示.

Fig.7 Error location time at different node scales圖7 不同節點規模下的錯誤定位時間

從趨勢上看，時間開銷在到達32 768 節點規模上仍然保持在秒級，并且時間開銷與進程規模的比值反而在下降，因此具有良好的可擴展性.

3.4 異常線程過濾方法

我們分別測量2 個超節點，并收集不同數量的計算節點的程序計數器的時間，圖8 顯示了耗時. 可以觀察到時間隨著計算節點數量的線性增長趨勢.

Fig.8 Time of data collection on different super nodes圖8 不同超節點上采集數據的時間

在測試中，當測量從n個計算節點收集數據的性能時，向n個連續節點提交作業，這意味著這些節點位于盡可能少的計算板上并且采集數據使用的維護處理器單元的數量是最少的. 該作業提交方案與資源管理系統盡可能將連續計算節點分配給資源隊列的策略以及作業管理系統向連續的計算節點提交并行作業的策略相一致. 在一個確定的規模，我們進行了10 次所有線程的程序計數器的采集，并報告了測量結果的平均值. 對于使用多個超節點資源的作業，可以通過并行采集進一步提高效率.

采集數據后的主要工作是將程序計數器不變的線程根據值分類. 我們在范圍2～128 的M下，在范圍從1 024 個節點（總計399 360 個核）到32 768 個節點（總計12 779 520 個核）的節點規模下測量處理時間.我們將每個線程控制到指定的掛起位置，使其屬于M類之一，因此處理耗費的時間最長.

圖9 顯示了處理時間. 可以看出，在每個M下處理時間隨著應用規模的增加而線性增加. 處理時間隨著M在每個尺度上的增長而增加，并且在最大規模和M=128 下該方法可以在0.7 s 內完成處理.

Fig.9 Data processing time at different scales圖9 不同規模下的數據處理時間

在圖10 中，我們可以更清楚地看到處理時間隨M線性增長的趨勢.M越高，該方法耗時越長. 但是，越高的M意味著越多線程掛起，這時用戶可能難以判斷異常線程. 根據經驗，當程序掛起時，M相對較低，因此處理時間也較短.

Fig.10 Data processing time of different PC types at 32 768 node圖10 32 768 節點時不同PC 類型的數據處理時間

采集到作業中所有線程的PC 值后，使用異常線程過濾方法可以定位到掛起線程，并生成其詳細信息.圖11 展示了HPL（high-performance linpack benchmark）運行中的一個診斷輸出，當執行函數slave_dgemm時，10 358 節點1 號核組上的41 413 號任務的8 個線程（編號為56～63 的從核）掛在了PC 為0x4ff0410bb0 的指令處，同時，在相應主核上的控制線程掛在了函數athread_join. 根據PC 值，可以判斷程序正在執行的語句為RMA（remote message access），掛起可能是由于計算核間的通信故障導致.

Fig.11 A diagnosis output in a HPL run圖11 HPL 運行中的診斷輸出

3.5 錯誤定位綜合測試

我們在32 768 節點環境下分別采用運行時故障定位架構和傳統錯誤定位方法開展綜合測試. 其中基于運行時故障定位方法通過并行執行3 種錯誤定位技術進行系統錯誤定位，傳統錯誤定位主要包括操作系統分析、維護系統分析和MPFL 故障分析.

測試設計了2 種測試集，分別是有明顯故障信息MsgSet1 測試集和無明顯故障信息MsgSet2 測試集.MsgSet1 主要包括處理器管理核心、處理器計算核心、存儲器、網絡接口、操作系統等錯誤；MsgSet2主要包括程序掛死、消息性能異常和消息丟包等無故障信息的錯誤現象. 通過基于運行時庫的錯誤定位和傳統的故障定位方法，比較時間開銷.

表2 顯示了傳統錯誤定位和運行時故障定位技術的時間開銷對比. 可以發現，由于MsgSet1 測試集產生的錯誤在操作系統日志和維護管理系統中有相關信息，定位效率較為高效.MsgSet2 測試過程中，由于該類錯誤沒有操作系統日志信息和硬件故障信息，導致操作系統日志分析和維護系統分析無法正常定位，只能通過運行時錯誤定位技術進行錯誤診斷. 其中基于運行時庫的錯誤探測分析技術可以對結果錯和消息丟包課題進行有效判斷；基于全局聚合信息的綜合診斷由于依賴錯誤信息分析，無法進行程序掛死和結果錯的故障定位；異常線程過濾方法彌補了上述2 個定位技術的缺項，通過核心PC 值的判斷，較好地定位了程序掛死問題.

Table 2 Comparison of Error Location Time表2 錯誤定位時間對比 s

通過測試，運行時錯誤定位和傳統的故障分析方法相比，針對無明顯故障信息的程序掛死等錯誤現象有較好的檢測及診斷效果，并通過技術融合，比較準確全面地分析出了發生錯誤的現場.

4 結 論

當前，并行計算技術已經邁入E 級計算時代，超級計算機的規模和復雜度越來越大，系統可靠性面臨前所未有的挑戰. 故障定位作為可靠性管理的核心技術，對實現超級計算機的高可用有重要意義，但當前的故障定位技術存在手段單一、對無明顯錯誤現象的故障缺乏有效定位方法的問題.

本文針對高性能計算系統中故障定位難度高且實時性差的問題，面向“新一代神威超級計算機”提出了一種運行時故障定位方法，包括基于消息傳遞的故障關聯分析、基于全局聚合信息的在線綜合分析診斷、面向申威眾核處理器的異常線程過濾方法等關鍵技術. 通過試驗可以發現，并行運行時故障定位技術具有較好的可擴展性，針對無日志信息、無明顯故障現象掛死等疑難問題有較好的適用性，可有效解決超大規模系統下的即時精準定位，提升系統平均無故障時間，為新一代超級計算的可靠性設計提供技術支撐.