田鴻運,劉 旭,武林平,羅紅兵,莫則堯
(1. 北京應用物理與計算數學研究所, 北京 100094; 2. 中物院高性能數值模擬軟件中心, 北京 100088)
并行作業特征分析是負載分析的重要基礎,對于超算系統裝備建設單位具有實際應用價值。通過并行作業統計特征分析,可以定量給出并行應用的機時使用情況、作業并行規模、作業運行成功率、運行波動率等作業特征,量化分析高性能計算應用的能力發展狀態及其對于超級計算機算力的需求,從而為系統容量配置、系統架構選型以及應用特征導向的系統能力評測、系統資源調度優化等研究提供參考[1-2]。例如,美國國家能源研究科學計算中心(national energy research scientific computing center, NERSC)針對其裝備的高性能計算機(Hopper-2011、Edison-2013、Cori-2016)定期發布作業數據分析報告,從應用科學領域、應用并行能力、編程語言、數學庫、內存使用、IO使用等多個維度詳細分析系統上的負載特征及其演化規律,進而形成相應的數值模擬應用-算法特征矩陣,指導系統評測基準程序的研制與選型和系統容量配置優化[3-6]。Michael等對美國國家超算應用中心(national center for super-computing applications, NCSA)的Blue Waters系統負載進行了分析研究[7-8],不僅從科學領域、應用、算法等方面開展了宏觀的負載統計分析,還從并行方式、內存使用、IO行為特征、異構資源使用特征等方面深入研究了該系統上的高性能計算應用特征,指導系統優化研究,引導下一代系統設計。橡樹嶺國家實驗室(Oak Ridge national laboratory, ORNL)的You等對該實驗室的Kraken計算機開展了作業特征統計分析研究[9],他們的研究著重于從作業并行規模、作業排隊時間、隊列資源利用率等角度研究資源的使用情況進而為調度優化提供參考。黃瑞芳等基于氣象海洋應用的計算特征分析,設計了面向氣象海洋應用的高性能計算機評測體系,他們的分析著重于定性分析[10]。
并行作業特征的量化分析主要基于作業記賬日志數據開展。Baer等開發了針對PBS作業管理系統的作業數據統計工具pbsacct[11],該工具不支持按照用戶需求自定義數據分析插件。Nielsen等開發的Slurm_tools[12],提供對于作業數據分析的統計腳本,但主要是對sacct和sreport的封裝,沒有提供應用維度的統計分析功能。LLNL實驗室開發的XDMoD,是一款針對并行作業管理系統的負載分析工具,但不支持用戶自定義數據統計分析插件[13]。
當前,基于作業記賬日志開展并行作業特征分析存在三個挑戰。首先,并行作業記賬日志數據中沒有記錄應用名稱,現有工具無法按應用名稱開展作業特征分析。其次,不同作業管理系統的作業記賬日志數據格式可能存在差別,對分析工具的跨平臺兼容性也提出了挑戰。此外,不同業務場景對于并行作業特征分析的側重點各有不同,多目標場景對于分析工具的功能可擴展性也提出了要求。
針對上述挑戰,提出了一種基于關鍵字模糊匹配的作業記賬日志應用名稱標記方法,為作業記賬日志增加應用名稱索引標簽,使作業記賬日志具備了從應用維度開展統計分析的能力。同時,設計了一種通用的作業數據描述模型,通過將作業記賬日志數據格式轉換為標準格式,屏蔽了不同作業管理系統記賬日志數據格式的差異,實現了作業數據統計分析與作業數據格式的解耦。針對多目標場景對軟件功能靈活性的挑戰,設計了支持插件定制的柔性可擴展軟件架構,支撐按需求定制開發作業數據分析插件。基于前述三項關鍵技術,集成實現了并行作業特征統計分析工具JobCAT(job characteristic analysis toolkit)。
資源管理系統是超級計算機中的重要基礎軟件,負責并行作業的資源分配、調度、管理、回收、記錄、查詢。目前,最為主流的并行作業管理系統有:SLURM(simple linux utility for resource management)、LSF(load share facility)、PBSpro(portable batch system professional)以及TORQUE(Terascale open-source resource and queue manager)等[14]。其中,SLURM是由美國勞倫斯·利弗莫爾國家實驗室(Lawrence Livermore national laboratory,LLNL)開發的一種可用于大型計算集群的資源管理器和作業調度系統,被全球范圍內的超級計算機廣泛使用[15]。下面以SLURM為例,介紹并行作業管理系統。
SLURM會為每個作業生成作業記賬日志數據,用戶可通過sacct查詢作業記賬數據。SLURM作業記賬日志字段如表1所示,sacct支持按起止日期、用戶名、作業ID等方式查詢,但不支持按應用名稱進行查詢[15]。

表1 SLURM作業記賬日志字段示例
SLURM作業記賬日志包括作業號記賬日志和作業步記賬日志兩部分。其中,作業號記賬日志的JobID為一個整數,作業步記賬日志的JobID在對應作業號記賬日志的基礎上增加作業步編號后綴。實際分析時需要將作業號記賬日志數據和作業步記賬日志數據合并才能得到一條完整的記賬日志數據信息。
SLURM支持用戶使用交互式、預分配式、批處理式三種方式提交并行作業。實際中,用戶常使用批處理方式。對于批處理方式提交的作業,作業號記賬日志的JobName字段對應于批處理腳本名稱,WorkDir字段對應于批處理腳本執行目錄,而作業步記賬日志中的JobName字段,則對應于作業名稱,WorkDir字段對應于作業執行目錄。
實際使用中,用戶為了區分不同版本的可執行程序文件,常會在可執行程序名稱或者作業執行腳本上附帶版本號、日期、用戶名等信息,或者將可執行程序按照領域內涵進行命名,將可執行程序名稱放入批處理作業腳本文件名中,導致同一個應用程序在作業記賬日志中的命名并不唯一。
此外,為了加快大規模作業的加載速度,用戶常常會組合使用多條作業執行命令,例如將作業投遞命令(如:srun)與數據分發命令(如:sbcast)組合使用,導致一個并行作業產生多條作業日志數據,而這些日志記錄中可能存在諸如mkdir、rm等輔助功能的命令,導致應用名稱易被錯誤標記。
上述用戶行為,導致實際的并行應用名稱在作業記賬日志中的位置、順序、大小寫沒有固定特征。應用名稱既可能存在于批處理腳本名稱中,也可能存在于某一個作業步的作業名稱中。同時,應用名稱大小寫也可能因為用戶命名習慣的差異而各不相同。用戶行為的差異,給作業記賬日志的應用名稱識別標記帶來挑戰。
為了應對并行作業記賬日志中作業名稱多樣性給應用名稱標記帶來的困難,提出一種基于關鍵字模糊匹配的作業記賬日志標記方法,如圖1所示。該方法的實現步驟如下:
1)建立應用關鍵字列表。將系統上的常見應用程序名稱和可忽略的作業名稱各建立一個關鍵字列表。以python為例,可以使用類似{"applist": ["app1", "app2", "app3"], "ignore_list": ["mkdir","rm"]}的字典格式存儲系統上的應用程序名稱和忽略作業名稱列表,并將其存入json格式的配置文件中,在工具啟動時動態加載解析。如果兩個程序的關鍵字存在包含關系,則字段長的關鍵字應列在前面。例如:lared-s和lared存在包含關系,則將lared-s寫在前面。對于應用名稱關鍵字字典和可忽略作業名稱字典,在后續測試中不斷補充完善。
2)作業日志自動分組。遍歷系統在指定時間段內的作業日志,按照jobid進行日志分組。設計一個臨時日志池logpool,然后開始遍歷作業日志。如果jobid不包含‘.’分隔符并且logpool為空,則表明是某作業日志的第一條日志記錄信息,將日志添加到logpool中;如果jobid不包含‘.’分隔符并且logpool非空,則表明是一條新的日志,先進行已分組日志的解析工作;如果jobid包含‘.’分隔符并且作業ID與當前解析的作業ID一致,則表明是當前解析作業的作業步日志,將其添加到當前的日志分組中;如果jobid包含‘.’分隔符并且其作業ID與當前解析的作業ID不一致,則表明是一條新的作業日志,先進行已分組日志的解析工作。
3)關鍵字模糊匹配遍歷。遍歷已分組日志的JobName和WorkDir字段,將其與應用名稱關鍵字字典進行遍歷匹配,匹配時不區分大小寫,如果匹配成功則返回。對于未識別的作業日志,表明日志中不包含應用名稱關鍵字,可能是由于用戶根據領域內涵對應用名稱進行了重命名,此時嘗試通過關鍵字重命名映射表找出作業的應用程序名。關鍵字重命名映射表是根據常見用戶習慣設置的作業名稱到實際可執行應用的映射表,通常這類用戶在不同系統上的命名習慣相同,從而可以使用相同的“關鍵字重命名映射表”。如果發現用戶在不同系統上的命名習慣不相同,也可以為每一臺超算系統設置不同的關鍵字重命名映射表。如果遍歷完關鍵字重命名映射表依然未能成功匹配,則將應用名稱標記為“unknown”。
4)數據合并。對于成功識別出應用程序名稱的作業日志,合并相應的作業步日志和該作業ID對應的首條日志信息,并將合并后的作業日志標記為指定應用的作業日志數據。

圖1 基于關鍵字模糊匹配的作業日志識別方法Fig.1 Job log recognition method based on keyword fuzzy matching
為了應對不同作業管理系統記賬日志格式的差異,設計了一種支持大綱格式檢查的通用作業數據描述模型,如圖 2所示。

圖2 統一作業數據格式Fig.2 Uniformed job account log
該模型將作業日志描述信息劃分為四個維度,分別是基本信息維度、時間信息維度、資源消耗信息維度以及其他信息維度。其中:①基本信息維度主要包含與作業描述最基本的相關要素,目前包含作業ID(JOBID)、作業名稱(JOBNAME)、應用名稱(AAPPNAME)、程序版本(VERSION)等7個字段;②時間信息維度包括與作業信息描述相關的時間要素,目前包含作業提交時間(SUBMIT)、作業開始運行時間(START)、作業結束運行時間(END)等6個字段;③資源消耗信息維度主要包括與CPU、內存、IO相關的要素,目前包含CPU核數(CPUS)、計算節點數(NODES)、機時(CPUTime,單位為核·s)等13個字段;④其他信息維度包括基本信息、時間信息、資源消耗信息之外的共性要素,目前包含作業返回狀態(STATE)、節點列表(NODELIST)等字段。
通過schema庫提供的大綱格式檢查功能,JobCAT實現了作業記賬日志數據的格式檢查。后續只需實現標準數據格式向各作業管理系統數據格式的轉換層,即可實現對相應作業管理系統的平滑移植,從而保證JobCAT的跨平臺兼容性。目前,JobCAT已經實現了對SLURM作業管理系統的數據格式轉換層支持。
為了靈活應對不同場景的作業數據分析需求,JobCAT實現了一套支持插件定制的柔性可擴展架構,如圖 3所示。主要通過插件模板、插件管理器、運行時管理器三部分協同實現。

圖3 JobCAT總體架構Fig.3 Architecture of JobCAT
插件模板包含doanalysis()、drawdatas()、help()等共性接口,doanalysis()和drawdatas()根據用戶需求定制實現,分別負責數據的分析與數據分析結果的輸出展示,help()提供了缺省實現,用戶可以選擇自行實現也可以選擇使用模板自帶的缺省實現。根據用戶需求定制實現的分析插件,通過注冊器注冊到插件管理器中即可被插件管理器自動識別并加載運行。
插件管理器負責搜索、加載、運行、管理插件,同時將運行時狀態信息傳遞給分析插件。
運行時管理器負責運行時配置參數的管理以及原始作業數據的查詢與轉換,通過運行時配置管理器,JobCAT可以選擇與當前系統平臺適配的作業數據格式轉換器進行數據查詢與格式轉換。運行時管理器根據用戶運行時輸入參數,動態查詢并轉換作業數據格式,并將其作為數據分析插件的輸入。運行時管理器由運行時配置管理器、作業負載數據管理器、SLURM數據格式轉換器三部分組成。其中,運行時配置管理器包含配置選項解析器(ConfigOptionParser)、配置選項管理器(ConfigOptionManager)、命令行參數管理器(CmdArgsManager)、命令行參數解析句柄(CmdArgsHandler)。作業負載數據管理器包含JobCAT日志格式模板(JobCATLogHeader)、JobCAT日志數據行抽象類(JobCATLogLine)以及JobCAT數據集(JobCATDataFrame)。SLURM數據格式轉換器負責SLURM作業記賬日志格式向JobCAT通用日志模型的轉換,包含作業記賬日志格式模板(SlurmHeaderIdx)、作業記賬日志解析器(SlurmLogFileParser)、作業記賬日志查詢器(SlurmLogQuery)、作業狀態修復工具(SlurmJobStateFixer)、作業記賬日志解析緩存池(SlurmLogPool)。
通過上述三項關鍵技術,JobCAT實現了作業記賬日志的應用識別標記,滿足了工具的跨平臺兼容性需求,支持根據業務分析場景開展定制分析。
JobCAT的插件清單見表2。目前JobCAT支持7個分析插件,共包含29項統計報表。這些功能插件可以為用戶提供超算資源使用分析、內存使用分析、應用特征分析等并行作業數據統計分析支持,進而支撐超算資源調度效率優化、計算節點內存容量配置優化設計、典型業務應用程序篩選等研究,為超算硬件能力建設服務。

表2 JobCAT的插件清單
JobCAT支持通過命令行參數選項,可以動態設置數據分析的起止日期、指定特定的目標用戶群體、應用程序集等,并支持根據需要動態加載分析插件。
JobCAT支持命令行與配置文件相結合的配置管理方式,對于系統平臺運行環境相關的配置參數,可通過配置文件設置。用戶還可在配置文件中靈活指定應用名稱關鍵字列表、作業并行規模分類器、作業運行時長分類器、文檔數據格式轉換器、用戶信息查詢緩存表等配置信息。與分析插件、命令行參數一樣,配置文件選項也可以按需靈活擴展。
實驗集群包含3 584個計算節點,共114 688個處理器核,系統峰值性能為2 803.2 TFlops,采用胖樹網絡拓撲,SLURM版本為v18.08.04,集群上共232位用戶。分別采用2018-05-01至2018-11-01、2018-05-01至2019-05-01、2018-05-01至2020-05-01三個時間段的作業記賬日志開展識別率驗證,并使用最后一時間段的作業記賬日志開展作業特征統計分析研究。
實際生產環境下,面向真實物理過程研究的科學計算數值模擬應用往往需要大規模、長時間運行,運行時間短的作業常常是調試作業。調試作業具有運行時間短、占用機時資源少、作業命名隨意性強的特點,因此,本文的并行作業特征統計分析主要針對生產型作業。結合實際經驗,將調試型作業的運行時長上限設為30 min。
(1)
式中:R為作業記賬日志識別率;Tunknown為未識別標記的作業記賬日志數;Ttotal_jobs為總日志數,由JobCAT自動統計。
通過對目標集群上的SLURM作業記賬日志數據庫進行分析處理,三個時段的作業記賬日志數據識別率如圖4所示。在三個統計時間段內,對于183 987、384 680、1 145 393條并行作業記賬日志,日志識別率R分別為98.97%、98.90%、97.11%。這表明JobCAT對于百萬量級作業記賬日志的識別率可達到95%以上。同時,從系統中隨機選擇20位用戶(約占總用戶數的10%)驗證這些用戶下的作業記賬日志識別正確性,實驗隨機選擇300條日志進行人工分析校驗,所有日志-應用的關聯都是正確的。通過日志-應用關聯識別,共有效標記了系統上的44個數值模擬業務應用并行程序。在三個統計時段內,未識別作業和調試作業占總機時的總和比例均小于5%,對于后續基于作業特征統計分析的典型應用篩選影響較小。

圖4 作業記賬日志數據識別率Fig.4 Recognition rate of job account log
對于未識別的作業,進一步分析發現,這些作業主要由兩類組成:一類是基于JASMIN框架編寫的程序,其可執行程序缺省命名為main2d或者main3d,開發者沒有將其根據實際程序進行命名,故而導致無法進行有效區分;另一類是用戶對可執行程序進行了匿名化處理,導致無法將其與具體的應用名稱建立關聯。
上述實驗數據表明,基于關鍵字模糊匹配的并行作業日志標記方法正確有效。根據文獻調研,LLNL的XDMoD對于作業記賬日志的識別率大于90%[7,13]。相比于XDMod,JobCAT增加了結合領域知識的應用名稱關鍵字重命名映射表,這可能是JobCAT作業日志識別率更高的原因。
JobCAT可以支持一鍵生成作業數據統計分析報告。報告生成的時間開銷與作業記賬日志數據量成正相關。實驗數據表明,對于數十萬量級的作業記賬日志數據,分析報告生成的時間開銷小于5 min。
作業數據統計分析報告包含總體情況分析、計算資源使用情況分析、應用特征分析、作業數據分析。
總體情況分析。包括資源可用率曲線、資源利用率曲線、作業排隊情況,它們可以作為超算資源運維管理效率和資源調度效率的衡量指標。資源可用率是衡量系統故障修復能力的重要指標;資源利用率是衡量資源利用率的重要指標;作業排隊情況可作為資源調度效率的參考。
計算資源使用情況分析。JobCAT按照用戶、團隊、科研業務方向分析統計區間內的計算使用情況,給出按照用戶、團隊、應用程序、并行規則、運行時長等多個維度的計算資源使用明細情況,從而幫助用戶服務更有針對性和指向性。
應用特征分析。JobCAT從9個維度開展應用程序作業特征分析,定量刻畫了實際系統上的應用程序業務特征,進而為研制系統評測程序提供參考依據。
作業數據分析。JobCAT給出了對內存、IO的資源使用情況的統計分析結果,可以反映實際業務應用對內存、IO資源的真實使用情況,從而為系統容量配置規劃提供參考依據。
JobCAT的設計遵循開放可擴展原則。按照作業特征分析場景的需求,開發了7個分析插件。本節列舉幾項最常用的數據分析功能。
3.4.1 系統運維效率指標統計
基于JobCAT,可以實現系統可用率、資源利用率、計算需求覆蓋率的自動統計。三項指標的定義分別如下:
(2)
(3)
(4)
Tqueue=∑tqueue·Ncpu
(5)
其中:Tavail為系統實際可用機時,Ttotal為系統理論可用機時,Tused為作業實際使用機時,Tqueue為作業排隊等效核時。Tavail、Ttotal、Tused由作業管理系統提供,Tqueue由JobCAT計算生成。Tqueue為計算隊列上排隊作業的等待時間與作業并行規模的乘積累加和。Ravail代表系統可用率,用于衡量系統故障運維能力;Rutil代表資源利用率可用于衡量資源使用情況,反映用戶上機意愿;Rcov代表作業排隊率(計算需求覆蓋率),可用于衡量資源調度能力。
如果統計區間內的系統可用率低,表明系統故障率高,此時應該加強系統檢修;如果統計區間內的資源利用率低,表明此時有較多的閑置計算資源,此時需要加強用戶溝通,促進計算資源的充分使用;如果統計區間內的作業排隊率高,計算需求覆蓋率低,并且資源利用率低,則表明資源調度策略可能存在優化空間。最為理想的狀態是:系統可用率、資源利用率、計算需求覆蓋率三者均維持在較高的水平。圖5為某千萬億次系統在一個月內的系統可用率與資源利用率統計。從圖5可以看出,在統計區間內,系統可用率一直維持在95%以上的水平,表明系統運維效率高。但是在7月5日和7月26日的資源利用率下降到了80%以下,表明在上述區間內用戶上機意愿不強,存在優化空間。

圖5 系統可用率與資源利用率統計Fig.5 Statistics of system availability and resource utilization
表3為隊列計算需求覆蓋率統計。從表3可見,統計區間內,主要計算隊列的計算需求覆蓋率均大于85%,表明系統在統計區間內的資源調度運行良好。

表3 隊列計算需求覆蓋率
3.4.2 并行應用活躍度統計
依托JobCAT對作業記賬日志數據從應用維度開展統計分析的能力,JobCAT可以給出系統上的并行應用程序活躍度統計分析。圖6和圖7所示分別是目標系統上的數值模擬應用程序用戶數量統計和數值模擬應用程序機時及作業數統計。通過上述統計圖表,可以量化分析系統上各個應用程序的機時使用情況,并根據程序的用戶數量、作業數量、機時數量來綜合評估應用活躍度。此外,JobCAT還可進一步給出應用程序的各個用戶對該程序的詳細使用情況(作業數、機時數、成功率),從而確定各個應用程序的主要用戶,為應用程序的用戶支撐服務提供參考。

圖6 應用程序用戶數量統計Fig.6 Statistics of application users

圖7 應用程序作業機時與作業數量統計Fig.7 Statistics of job node hour and quantity
3.4.3 應用宏觀特征統計分析
JobCAT可以統計分析并行應用在系統上的運行特征,圖8給出的是某系統上的主力應用程序的并行規模分布情況和各應用程序的單進程平均內存使用情況統計。圖8使用箱體圖分別展示了應用程序的并行規模分布圖和應用程序的平均內存使用量。箱體圖內的橙色實體代表中位數,箱體圖的實體部分代表有50%的樣本處于實體區間內,圓圈代表異常樣本。上述統計圖可以反映各應用程序的作業主要并行規模分布區間、作業的最大并行規模、作業的單進程平均內存使用量等信息。

(a) 作業并行規模分布(a) Job′s parallel processes distribution
除此之外,JobCAT還可給出各程序的單進程最大內存使用量、作業級的內存使用量、IO讀寫數據量、作業的運行時長分布、作業運行時長與作業并行規模的關系圖等統計數據。這些數據可以從不同角度準確刻畫各應用程序在生產環境下對計算資源的使用需求,從而為系統容量規劃提供科學參考依據。同時,也可以為并行程序的性能優化提供輔助參考。
3.4.4 應用負載特征雷達圖
基于JobCAT對并行應用作業特征的統計分析,可以進一步對并行應用特征開展多維度的量化建模分析研究。圖9為應用負載特征統計雷達圖示例。該圖從應用活躍度、作業成功率排名、性能波動率、典型并行規模排名等13個維度刻畫了并行應用的負載特征,可為典型應用篩選提供依據。關于應用負載特征建模的量化分析已經超出了本文的范疇,這里不做展開。

圖9 應用負載特征雷達Fig.9 Radar chart of application′s workload characteristics
基于應用的作業特征分析是高性能計算負載分析研究的重要基礎。作業記賬日志數據是開展并行作業特征分析的數據源頭。針對并行作業特征分析中存在的作業數據識別困難、數據格式不統一、目標場景多樣化等問題,本文分別提出了三項關鍵技術,并集成實現了作業特征分析工具JobCAT。
通過百萬量級作業記賬日志數據的測試驗證,JobCAT的作業記賬日志標記率大于95%,這一能力優于LLNL的同類工具XDMoD。JobCAT支持7個插件、29項統計報表,可一鍵生成應用的作業特征分析報告,對應用負載分析研究具有實用價值。