田鴻運,劉 旭,武林平,羅紅兵,莫則堯
(1. 北京應(yīng)用物理與計算數(shù)學研究所, 北京 100094; 2. 中物院高性能數(shù)值模擬軟件中心, 北京 100088)
并行作業(yè)特征分析是負載分析的重要基礎(chǔ),對于超算系統(tǒng)裝備建設(shè)單位具有實際應(yīng)用價值。通過并行作業(yè)統(tǒng)計特征分析,可以定量給出并行應(yīng)用的機時使用情況、作業(yè)并行規(guī)模、作業(yè)運行成功率、運行波動率等作業(yè)特征,量化分析高性能計算應(yīng)用的能力發(fā)展狀態(tài)及其對于超級計算機算力的需求,從而為系統(tǒng)容量配置、系統(tǒng)架構(gòu)選型以及應(yīng)用特征導向的系統(tǒng)能力評測、系統(tǒng)資源調(diào)度優(yōu)化等研究提供參考[1-2]。例如,美國國家能源研究科學計算中心(national energy research scientific computing center, NERSC)針對其裝備的高性能計算機(Hopper-2011、Edison-2013、Cori-2016)定期發(fā)布作業(yè)數(shù)據(jù)分析報告,從應(yīng)用科學領(lǐng)域、應(yīng)用并行能力、編程語言、數(shù)學庫、內(nèi)存使用、IO使用等多個維度詳細分析系統(tǒng)上的負載特征及其演化規(guī)律,進而形成相應(yīng)的數(shù)值模擬應(yīng)用-算法特征矩陣,指導系統(tǒng)評測基準程序的研制與選型和系統(tǒng)容量配置優(yōu)化[3-6]。Michael等對美國國家超算應(yīng)用中心(national center for super-computing applications, NCSA)的Blue Waters系統(tǒng)負載進行了分析研究[7-8],不僅從科學領(lǐng)域、應(yīng)用、算法等方面開展了宏觀的負載統(tǒng)計分析,還從并行方式、內(nèi)存使用、IO行為特征、異構(gòu)資源使用特征等方面深入研究了該系統(tǒng)上的高性能計算應(yīng)用特征,指導系統(tǒng)優(yōu)化研究,引導下一代系統(tǒng)設(shè)計。橡樹嶺國家實驗室(Oak Ridge national laboratory, ORNL)的You等對該實驗室的Kraken計算機開展了作業(yè)特征統(tǒng)計分析研究[9],他們的研究著重于從作業(yè)并行規(guī)模、作業(yè)排隊時間、隊列資源利用率等角度研究資源的使用情況進而為調(diào)度優(yōu)化提供參考。黃瑞芳等基于氣象海洋應(yīng)用的計算特征分析,設(shè)計了面向氣象海洋應(yīng)用的高性能計算機評測體系,他們的分析著重于定性分析[10]。
并行作業(yè)特征的量化分析主要基于作業(yè)記賬日志數(shù)據(jù)開展。Baer等開發(fā)了針對PBS作業(yè)管理系統(tǒng)的作業(yè)數(shù)據(jù)統(tǒng)計工具pbsacct[11],該工具不支持按照用戶需求自定義數(shù)據(jù)分析插件。Nielsen等開發(fā)的Slurm_tools[12],提供對于作業(yè)數(shù)據(jù)分析的統(tǒng)計腳本,但主要是對sacct和sreport的封裝,沒有提供應(yīng)用維度的統(tǒng)計分析功能。LLNL實驗室開發(fā)的XDMoD,是一款針對并行作業(yè)管理系統(tǒng)的負載分析工具,但不支持用戶自定義數(shù)據(jù)統(tǒng)計分析插件[13]。
當前,基于作業(yè)記賬日志開展并行作業(yè)特征分析存在三個挑戰(zhàn)。首先,并行作業(yè)記賬日志數(shù)據(jù)中沒有記錄應(yīng)用名稱,現(xiàn)有工具無法按應(yīng)用名稱開展作業(yè)特征分析。其次,不同作業(yè)管理系統(tǒng)的作業(yè)記賬日志數(shù)據(jù)格式可能存在差別,對分析工具的跨平臺兼容性也提出了挑戰(zhàn)。此外,不同業(yè)務(wù)場景對于并行作業(yè)特征分析的側(cè)重點各有不同,多目標場景對于分析工具的功能可擴展性也提出了要求。
針對上述挑戰(zhàn),提出了一種基于關(guān)鍵字模糊匹配的作業(yè)記賬日志應(yīng)用名稱標記方法,為作業(yè)記賬日志增加應(yīng)用名稱索引標簽,使作業(yè)記賬日志具備了從應(yīng)用維度開展統(tǒng)計分析的能力。同時,設(shè)計了一種通用的作業(yè)數(shù)據(jù)描述模型,通過將作業(yè)記賬日志數(shù)據(jù)格式轉(zhuǎn)換為標準格式,屏蔽了不同作業(yè)管理系統(tǒng)記賬日志數(shù)據(jù)格式的差異,實現(xiàn)了作業(yè)數(shù)據(jù)統(tǒng)計分析與作業(yè)數(shù)據(jù)格式的解耦。針對多目標場景對軟件功能靈活性的挑戰(zhàn),設(shè)計了支持插件定制的柔性可擴展軟件架構(gòu),支撐按需求定制開發(fā)作業(yè)數(shù)據(jù)分析插件?;谇笆鋈楆P(guān)鍵技術(shù),集成實現(xiàn)了并行作業(yè)特征統(tǒng)計分析工具JobCAT(job characteristic analysis toolkit)。
資源管理系統(tǒng)是超級計算機中的重要基礎(chǔ)軟件,負責并行作業(yè)的資源分配、調(diào)度、管理、回收、記錄、查詢。目前,最為主流的并行作業(yè)管理系統(tǒng)有: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)開發(fā)的一種可用于大型計算集群的資源管理器和作業(yè)調(diào)度系統(tǒng),被全球范圍內(nèi)的超級計算機廣泛使用[15]。下面以SLURM為例,介紹并行作業(yè)管理系統(tǒng)。
SLURM會為每個作業(yè)生成作業(yè)記賬日志數(shù)據(jù),用戶可通過sacct查詢作業(yè)記賬數(shù)據(jù)。SLURM作業(yè)記賬日志字段如表1所示,sacct支持按起止日期、用戶名、作業(yè)ID等方式查詢,但不支持按應(yīng)用名稱進行查詢[15]。
表1 SLURM作業(yè)記賬日志字段示例
SLURM作業(yè)記賬日志包括作業(yè)號記賬日志和作業(yè)步記賬日志兩部分。其中,作業(yè)號記賬日志的JobID為一個整數(shù),作業(yè)步記賬日志的JobID在對應(yīng)作業(yè)號記賬日志的基礎(chǔ)上增加作業(yè)步編號后綴。實際分析時需要將作業(yè)號記賬日志數(shù)據(jù)和作業(yè)步記賬日志數(shù)據(jù)合并才能得到一條完整的記賬日志數(shù)據(jù)信息。
SLURM支持用戶使用交互式、預分配式、批處理式三種方式提交并行作業(yè)。實際中,用戶常使用批處理方式。對于批處理方式提交的作業(yè),作業(yè)號記賬日志的JobName字段對應(yīng)于批處理腳本名稱,WorkDir字段對應(yīng)于批處理腳本執(zhí)行目錄,而作業(yè)步記賬日志中的JobName字段,則對應(yīng)于作業(yè)名稱,WorkDir字段對應(yīng)于作業(yè)執(zhí)行目錄。
實際使用中,用戶為了區(qū)分不同版本的可執(zhí)行程序文件,常會在可執(zhí)行程序名稱或者作業(yè)執(zhí)行腳本上附帶版本號、日期、用戶名等信息,或者將可執(zhí)行程序按照領(lǐng)域內(nèi)涵進行命名,將可執(zhí)行程序名稱放入批處理作業(yè)腳本文件名中,導致同一個應(yīng)用程序在作業(yè)記賬日志中的命名并不唯一。
此外,為了加快大規(guī)模作業(yè)的加載速度,用戶常常會組合使用多條作業(yè)執(zhí)行命令,例如將作業(yè)投遞命令(如:srun)與數(shù)據(jù)分發(fā)命令(如:sbcast)組合使用,導致一個并行作業(yè)產(chǎn)生多條作業(yè)日志數(shù)據(jù),而這些日志記錄中可能存在諸如mkdir、rm等輔助功能的命令,導致應(yīng)用名稱易被錯誤標記。
上述用戶行為,導致實際的并行應(yīng)用名稱在作業(yè)記賬日志中的位置、順序、大小寫沒有固定特征。應(yīng)用名稱既可能存在于批處理腳本名稱中,也可能存在于某一個作業(yè)步的作業(yè)名稱中。同時,應(yīng)用名稱大小寫也可能因為用戶命名習慣的差異而各不相同。用戶行為的差異,給作業(yè)記賬日志的應(yīng)用名稱識別標記帶來挑戰(zhàn)。
為了應(yīng)對并行作業(yè)記賬日志中作業(yè)名稱多樣性給應(yīng)用名稱標記帶來的困難,提出一種基于關(guān)鍵字模糊匹配的作業(yè)記賬日志標記方法,如圖1所示。該方法的實現(xiàn)步驟如下:
1)建立應(yīng)用關(guān)鍵字列表。將系統(tǒng)上的常見應(yīng)用程序名稱和可忽略的作業(yè)名稱各建立一個關(guān)鍵字列表。以python為例,可以使用類似{"applist": ["app1", "app2", "app3"], "ignore_list": ["mkdir","rm"]}的字典格式存儲系統(tǒng)上的應(yīng)用程序名稱和忽略作業(yè)名稱列表,并將其存入json格式的配置文件中,在工具啟動時動態(tài)加載解析。如果兩個程序的關(guān)鍵字存在包含關(guān)系,則字段長的關(guān)鍵字應(yīng)列在前面。例如:lared-s和lared存在包含關(guān)系,則將lared-s寫在前面。對于應(yīng)用名稱關(guān)鍵字字典和可忽略作業(yè)名稱字典,在后續(xù)測試中不斷補充完善。
2)作業(yè)日志自動分組。遍歷系統(tǒng)在指定時間段內(nèi)的作業(yè)日志,按照jobid進行日志分組。設(shè)計一個臨時日志池logpool,然后開始遍歷作業(yè)日志。如果jobid不包含‘.’分隔符并且logpool為空,則表明是某作業(yè)日志的第一條日志記錄信息,將日志添加到logpool中;如果jobid不包含‘.’分隔符并且logpool非空,則表明是一條新的日志,先進行已分組日志的解析工作;如果jobid包含‘.’分隔符并且作業(yè)ID與當前解析的作業(yè)ID一致,則表明是當前解析作業(yè)的作業(yè)步日志,將其添加到當前的日志分組中;如果jobid包含‘.’分隔符并且其作業(yè)ID與當前解析的作業(yè)ID不一致,則表明是一條新的作業(yè)日志,先進行已分組日志的解析工作。
3)關(guān)鍵字模糊匹配遍歷。遍歷已分組日志的JobName和WorkDir字段,將其與應(yīng)用名稱關(guān)鍵字字典進行遍歷匹配,匹配時不區(qū)分大小寫,如果匹配成功則返回。對于未識別的作業(yè)日志,表明日志中不包含應(yīng)用名稱關(guān)鍵字,可能是由于用戶根據(jù)領(lǐng)域內(nèi)涵對應(yīng)用名稱進行了重命名,此時嘗試通過關(guān)鍵字重命名映射表找出作業(yè)的應(yīng)用程序名。關(guān)鍵字重命名映射表是根據(jù)常見用戶習慣設(shè)置的作業(yè)名稱到實際可執(zhí)行應(yīng)用的映射表,通常這類用戶在不同系統(tǒng)上的命名習慣相同,從而可以使用相同的“關(guān)鍵字重命名映射表”。如果發(fā)現(xiàn)用戶在不同系統(tǒng)上的命名習慣不相同,也可以為每一臺超算系統(tǒng)設(shè)置不同的關(guān)鍵字重命名映射表。如果遍歷完關(guān)鍵字重命名映射表依然未能成功匹配,則將應(yīng)用名稱標記為“unknown”。
4)數(shù)據(jù)合并。對于成功識別出應(yīng)用程序名稱的作業(yè)日志,合并相應(yīng)的作業(yè)步日志和該作業(yè)ID對應(yīng)的首條日志信息,并將合并后的作業(yè)日志標記為指定應(yīng)用的作業(yè)日志數(shù)據(jù)。
圖1 基于關(guān)鍵字模糊匹配的作業(yè)日志識別方法Fig.1 Job log recognition method based on keyword fuzzy matching
為了應(yīng)對不同作業(yè)管理系統(tǒng)記賬日志格式的差異,設(shè)計了一種支持大綱格式檢查的通用作業(yè)數(shù)據(jù)描述模型,如圖 2所示。
圖2 統(tǒng)一作業(yè)數(shù)據(jù)格式Fig.2 Uniformed job account log
該模型將作業(yè)日志描述信息劃分為四個維度,分別是基本信息維度、時間信息維度、資源消耗信息維度以及其他信息維度。其中:①基本信息維度主要包含與作業(yè)描述最基本的相關(guān)要素,目前包含作業(yè)ID(JOBID)、作業(yè)名稱(JOBNAME)、應(yīng)用名稱(AAPPNAME)、程序版本(VERSION)等7個字段;②時間信息維度包括與作業(yè)信息描述相關(guān)的時間要素,目前包含作業(yè)提交時間(SUBMIT)、作業(yè)開始運行時間(START)、作業(yè)結(jié)束運行時間(END)等6個字段;③資源消耗信息維度主要包括與CPU、內(nèi)存、IO相關(guān)的要素,目前包含CPU核數(shù)(CPUS)、計算節(jié)點數(shù)(NODES)、機時(CPUTime,單位為核·s)等13個字段;④其他信息維度包括基本信息、時間信息、資源消耗信息之外的共性要素,目前包含作業(yè)返回狀態(tài)(STATE)、節(jié)點列表(NODELIST)等字段。
通過schema庫提供的大綱格式檢查功能,JobCAT實現(xiàn)了作業(yè)記賬日志數(shù)據(jù)的格式檢查。后續(xù)只需實現(xiàn)標準數(shù)據(jù)格式向各作業(yè)管理系統(tǒng)數(shù)據(jù)格式的轉(zhuǎn)換層,即可實現(xiàn)對相應(yīng)作業(yè)管理系統(tǒng)的平滑移植,從而保證JobCAT的跨平臺兼容性。目前,JobCAT已經(jīng)實現(xiàn)了對SLURM作業(yè)管理系統(tǒng)的數(shù)據(jù)格式轉(zhuǎn)換層支持。
為了靈活應(yīng)對不同場景的作業(yè)數(shù)據(jù)分析需求,JobCAT實現(xiàn)了一套支持插件定制的柔性可擴展架構(gòu),如圖 3所示。主要通過插件模板、插件管理器、運行時管理器三部分協(xié)同實現(xiàn)。
圖3 JobCAT總體架構(gòu)Fig.3 Architecture of JobCAT
插件模板包含doanalysis()、drawdatas()、help()等共性接口,doanalysis()和drawdatas()根據(jù)用戶需求定制實現(xiàn),分別負責數(shù)據(jù)的分析與數(shù)據(jù)分析結(jié)果的輸出展示,help()提供了缺省實現(xiàn),用戶可以選擇自行實現(xiàn)也可以選擇使用模板自帶的缺省實現(xiàn)。根據(jù)用戶需求定制實現(xiàn)的分析插件,通過注冊器注冊到插件管理器中即可被插件管理器自動識別并加載運行。
插件管理器負責搜索、加載、運行、管理插件,同時將運行時狀態(tài)信息傳遞給分析插件。
運行時管理器負責運行時配置參數(shù)的管理以及原始作業(yè)數(shù)據(jù)的查詢與轉(zhuǎn)換,通過運行時配置管理器,JobCAT可以選擇與當前系統(tǒng)平臺適配的作業(yè)數(shù)據(jù)格式轉(zhuǎn)換器進行數(shù)據(jù)查詢與格式轉(zhuǎn)換。運行時管理器根據(jù)用戶運行時輸入?yún)?shù),動態(tài)查詢并轉(zhuǎn)換作業(yè)數(shù)據(jù)格式,并將其作為數(shù)據(jù)分析插件的輸入。運行時管理器由運行時配置管理器、作業(yè)負載數(shù)據(jù)管理器、SLURM數(shù)據(jù)格式轉(zhuǎn)換器三部分組成。其中,運行時配置管理器包含配置選項解析器(ConfigOptionParser)、配置選項管理器(ConfigOptionManager)、命令行參數(shù)管理器(CmdArgsManager)、命令行參數(shù)解析句柄(CmdArgsHandler)。作業(yè)負載數(shù)據(jù)管理器包含JobCAT日志格式模板(JobCATLogHeader)、JobCAT日志數(shù)據(jù)行抽象類(JobCATLogLine)以及JobCAT數(shù)據(jù)集(JobCATDataFrame)。SLURM數(shù)據(jù)格式轉(zhuǎn)換器負責SLURM作業(yè)記賬日志格式向JobCAT通用日志模型的轉(zhuǎn)換,包含作業(yè)記賬日志格式模板(SlurmHeaderIdx)、作業(yè)記賬日志解析器(SlurmLogFileParser)、作業(yè)記賬日志查詢器(SlurmLogQuery)、作業(yè)狀態(tài)修復工具(SlurmJobStateFixer)、作業(yè)記賬日志解析緩存池(SlurmLogPool)。
通過上述三項關(guān)鍵技術(shù),JobCAT實現(xiàn)了作業(yè)記賬日志的應(yīng)用識別標記,滿足了工具的跨平臺兼容性需求,支持根據(jù)業(yè)務(wù)分析場景開展定制分析。
JobCAT的插件清單見表2。目前JobCAT支持7個分析插件,共包含29項統(tǒng)計報表。這些功能插件可以為用戶提供超算資源使用分析、內(nèi)存使用分析、應(yīng)用特征分析等并行作業(yè)數(shù)據(jù)統(tǒng)計分析支持,進而支撐超算資源調(diào)度效率優(yōu)化、計算節(jié)點內(nèi)存容量配置優(yōu)化設(shè)計、典型業(yè)務(wù)應(yīng)用程序篩選等研究,為超算硬件能力建設(shè)服務(wù)。
表2 JobCAT的插件清單
JobCAT支持通過命令行參數(shù)選項,可以動態(tài)設(shè)置數(shù)據(jù)分析的起止日期、指定特定的目標用戶群體、應(yīng)用程序集等,并支持根據(jù)需要動態(tài)加載分析插件。
JobCAT支持命令行與配置文件相結(jié)合的配置管理方式,對于系統(tǒng)平臺運行環(huán)境相關(guān)的配置參數(shù),可通過配置文件設(shè)置。用戶還可在配置文件中靈活指定應(yīng)用名稱關(guān)鍵字列表、作業(yè)并行規(guī)模分類器、作業(yè)運行時長分類器、文檔數(shù)據(jù)格式轉(zhuǎn)換器、用戶信息查詢緩存表等配置信息。與分析插件、命令行參數(shù)一樣,配置文件選項也可以按需靈活擴展。
實驗集群包含3 584個計算節(jié)點,共114 688個處理器核,系統(tǒng)峰值性能為2 803.2 TFlops,采用胖樹網(wǎng)絡(luò)拓撲,SLURM版本為v18.08.04,集群上共232位用戶。分別采用2018-05-01至2018-11-01、2018-05-01至2019-05-01、2018-05-01至2020-05-01三個時間段的作業(yè)記賬日志開展識別率驗證,并使用最后一時間段的作業(yè)記賬日志開展作業(yè)特征統(tǒng)計分析研究。
實際生產(chǎn)環(huán)境下,面向真實物理過程研究的科學計算數(shù)值模擬應(yīng)用往往需要大規(guī)模、長時間運行,運行時間短的作業(yè)常常是調(diào)試作業(yè)。調(diào)試作業(yè)具有運行時間短、占用機時資源少、作業(yè)命名隨意性強的特點,因此,本文的并行作業(yè)特征統(tǒng)計分析主要針對生產(chǎn)型作業(yè)。結(jié)合實際經(jīng)驗,將調(diào)試型作業(yè)的運行時長上限設(shè)為30 min。
(1)
式中:R為作業(yè)記賬日志識別率;Tunknown為未識別標記的作業(yè)記賬日志數(shù);Ttotal_jobs為總?cè)罩緮?shù),由JobCAT自動統(tǒng)計。
通過對目標集群上的SLURM作業(yè)記賬日志數(shù)據(jù)庫進行分析處理,三個時段的作業(yè)記賬日志數(shù)據(jù)識別率如圖4所示。在三個統(tǒng)計時間段內(nèi),對于183 987、384 680、1 145 393條并行作業(yè)記賬日志,日志識別率R分別為98.97%、98.90%、97.11%。這表明JobCAT對于百萬量級作業(yè)記賬日志的識別率可達到95%以上。同時,從系統(tǒng)中隨機選擇20位用戶(約占總用戶數(shù)的10%)驗證這些用戶下的作業(yè)記賬日志識別正確性,實驗隨機選擇300條日志進行人工分析校驗,所有日志-應(yīng)用的關(guān)聯(lián)都是正確的。通過日志-應(yīng)用關(guān)聯(lián)識別,共有效標記了系統(tǒng)上的44個數(shù)值模擬業(yè)務(wù)應(yīng)用并行程序。在三個統(tǒng)計時段內(nèi),未識別作業(yè)和調(diào)試作業(yè)占總機時的總和比例均小于5%,對于后續(xù)基于作業(yè)特征統(tǒng)計分析的典型應(yīng)用篩選影響較小。
圖4 作業(yè)記賬日志數(shù)據(jù)識別率Fig.4 Recognition rate of job account log
對于未識別的作業(yè),進一步分析發(fā)現(xiàn),這些作業(yè)主要由兩類組成:一類是基于JASMIN框架編寫的程序,其可執(zhí)行程序缺省命名為main2d或者main3d,開發(fā)者沒有將其根據(jù)實際程序進行命名,故而導致無法進行有效區(qū)分;另一類是用戶對可執(zhí)行程序進行了匿名化處理,導致無法將其與具體的應(yīng)用名稱建立關(guān)聯(lián)。
上述實驗數(shù)據(jù)表明,基于關(guān)鍵字模糊匹配的并行作業(yè)日志標記方法正確有效。根據(jù)文獻調(diào)研,LLNL的XDMoD對于作業(yè)記賬日志的識別率大于90%[7,13]。相比于XDMod,JobCAT增加了結(jié)合領(lǐng)域知識的應(yīng)用名稱關(guān)鍵字重命名映射表,這可能是JobCAT作業(yè)日志識別率更高的原因。
JobCAT可以支持一鍵生成作業(yè)數(shù)據(jù)統(tǒng)計分析報告。報告生成的時間開銷與作業(yè)記賬日志數(shù)據(jù)量成正相關(guān)。實驗數(shù)據(jù)表明,對于數(shù)十萬量級的作業(yè)記賬日志數(shù)據(jù),分析報告生成的時間開銷小于5 min。
作業(yè)數(shù)據(jù)統(tǒng)計分析報告包含總體情況分析、計算資源使用情況分析、應(yīng)用特征分析、作業(yè)數(shù)據(jù)分析。
總體情況分析。包括資源可用率曲線、資源利用率曲線、作業(yè)排隊情況,它們可以作為超算資源運維管理效率和資源調(diào)度效率的衡量指標。資源可用率是衡量系統(tǒng)故障修復能力的重要指標;資源利用率是衡量資源利用率的重要指標;作業(yè)排隊情況可作為資源調(diào)度效率的參考。
計算資源使用情況分析。JobCAT按照用戶、團隊、科研業(yè)務(wù)方向分析統(tǒng)計區(qū)間內(nèi)的計算使用情況,給出按照用戶、團隊、應(yīng)用程序、并行規(guī)則、運行時長等多個維度的計算資源使用明細情況,從而幫助用戶服務(wù)更有針對性和指向性。
應(yīng)用特征分析。JobCAT從9個維度開展應(yīng)用程序作業(yè)特征分析,定量刻畫了實際系統(tǒng)上的應(yīng)用程序業(yè)務(wù)特征,進而為研制系統(tǒng)評測程序提供參考依據(jù)。
作業(yè)數(shù)據(jù)分析。JobCAT給出了對內(nèi)存、IO的資源使用情況的統(tǒng)計分析結(jié)果,可以反映實際業(yè)務(wù)應(yīng)用對內(nèi)存、IO資源的真實使用情況,從而為系統(tǒng)容量配置規(guī)劃提供參考依據(jù)。
JobCAT的設(shè)計遵循開放可擴展原則。按照作業(yè)特征分析場景的需求,開發(fā)了7個分析插件。本節(jié)列舉幾項最常用的數(shù)據(jù)分析功能。
3.4.1 系統(tǒng)運維效率指標統(tǒng)計
基于JobCAT,可以實現(xiàn)系統(tǒng)可用率、資源利用率、計算需求覆蓋率的自動統(tǒng)計。三項指標的定義分別如下:
(2)
(3)
(4)
Tqueue=∑tqueue·Ncpu
(5)
其中:Tavail為系統(tǒng)實際可用機時,Ttotal為系統(tǒng)理論可用機時,Tused為作業(yè)實際使用機時,Tqueue為作業(yè)排隊等效核時。Tavail、Ttotal、Tused由作業(yè)管理系統(tǒng)提供,Tqueue由JobCAT計算生成。Tqueue為計算隊列上排隊作業(yè)的等待時間與作業(yè)并行規(guī)模的乘積累加和。Ravail代表系統(tǒng)可用率,用于衡量系統(tǒng)故障運維能力;Rutil代表資源利用率可用于衡量資源使用情況,反映用戶上機意愿;Rcov代表作業(yè)排隊率(計算需求覆蓋率),可用于衡量資源調(diào)度能力。
如果統(tǒng)計區(qū)間內(nèi)的系統(tǒng)可用率低,表明系統(tǒng)故障率高,此時應(yīng)該加強系統(tǒng)檢修;如果統(tǒng)計區(qū)間內(nèi)的資源利用率低,表明此時有較多的閑置計算資源,此時需要加強用戶溝通,促進計算資源的充分使用;如果統(tǒng)計區(qū)間內(nèi)的作業(yè)排隊率高,計算需求覆蓋率低,并且資源利用率低,則表明資源調(diào)度策略可能存在優(yōu)化空間。最為理想的狀態(tài)是:系統(tǒng)可用率、資源利用率、計算需求覆蓋率三者均維持在較高的水平。圖5為某千萬億次系統(tǒng)在一個月內(nèi)的系統(tǒng)可用率與資源利用率統(tǒng)計。從圖5可以看出,在統(tǒng)計區(qū)間內(nèi),系統(tǒng)可用率一直維持在95%以上的水平,表明系統(tǒng)運維效率高。但是在7月5日和7月26日的資源利用率下降到了80%以下,表明在上述區(qū)間內(nèi)用戶上機意愿不強,存在優(yōu)化空間。
圖5 系統(tǒng)可用率與資源利用率統(tǒng)計Fig.5 Statistics of system availability and resource utilization
表3為隊列計算需求覆蓋率統(tǒng)計。從表3可見,統(tǒng)計區(qū)間內(nèi),主要計算隊列的計算需求覆蓋率均大于85%,表明系統(tǒng)在統(tǒng)計區(qū)間內(nèi)的資源調(diào)度運行良好。
表3 隊列計算需求覆蓋率
3.4.2 并行應(yīng)用活躍度統(tǒng)計
依托JobCAT對作業(yè)記賬日志數(shù)據(jù)從應(yīng)用維度開展統(tǒng)計分析的能力,JobCAT可以給出系統(tǒng)上的并行應(yīng)用程序活躍度統(tǒng)計分析。圖6和圖7所示分別是目標系統(tǒng)上的數(shù)值模擬應(yīng)用程序用戶數(shù)量統(tǒng)計和數(shù)值模擬應(yīng)用程序機時及作業(yè)數(shù)統(tǒng)計。通過上述統(tǒng)計圖表,可以量化分析系統(tǒng)上各個應(yīng)用程序的機時使用情況,并根據(jù)程序的用戶數(shù)量、作業(yè)數(shù)量、機時數(shù)量來綜合評估應(yīng)用活躍度。此外,JobCAT還可進一步給出應(yīng)用程序的各個用戶對該程序的詳細使用情況(作業(yè)數(shù)、機時數(shù)、成功率),從而確定各個應(yīng)用程序的主要用戶,為應(yīng)用程序的用戶支撐服務(wù)提供參考。
圖6 應(yīng)用程序用戶數(shù)量統(tǒng)計Fig.6 Statistics of application users
圖7 應(yīng)用程序作業(yè)機時與作業(yè)數(shù)量統(tǒng)計Fig.7 Statistics of job node hour and quantity
3.4.3 應(yīng)用宏觀特征統(tǒng)計分析
JobCAT可以統(tǒng)計分析并行應(yīng)用在系統(tǒng)上的運行特征,圖8給出的是某系統(tǒng)上的主力應(yīng)用程序的并行規(guī)模分布情況和各應(yīng)用程序的單進程平均內(nèi)存使用情況統(tǒng)計。圖8使用箱體圖分別展示了應(yīng)用程序的并行規(guī)模分布圖和應(yīng)用程序的平均內(nèi)存使用量。箱體圖內(nèi)的橙色實體代表中位數(shù),箱體圖的實體部分代表有50%的樣本處于實體區(qū)間內(nèi),圓圈代表異常樣本。上述統(tǒng)計圖可以反映各應(yīng)用程序的作業(yè)主要并行規(guī)模分布區(qū)間、作業(yè)的最大并行規(guī)模、作業(yè)的單進程平均內(nèi)存使用量等信息。
(a) 作業(yè)并行規(guī)模分布(a) Job′s parallel processes distribution
除此之外,JobCAT還可給出各程序的單進程最大內(nèi)存使用量、作業(yè)級的內(nèi)存使用量、IO讀寫數(shù)據(jù)量、作業(yè)的運行時長分布、作業(yè)運行時長與作業(yè)并行規(guī)模的關(guān)系圖等統(tǒng)計數(shù)據(jù)。這些數(shù)據(jù)可以從不同角度準確刻畫各應(yīng)用程序在生產(chǎn)環(huán)境下對計算資源的使用需求,從而為系統(tǒng)容量規(guī)劃提供科學參考依據(jù)。同時,也可以為并行程序的性能優(yōu)化提供輔助參考。
3.4.4 應(yīng)用負載特征雷達圖
基于JobCAT對并行應(yīng)用作業(yè)特征的統(tǒng)計分析,可以進一步對并行應(yīng)用特征開展多維度的量化建模分析研究。圖9為應(yīng)用負載特征統(tǒng)計雷達圖示例。該圖從應(yīng)用活躍度、作業(yè)成功率排名、性能波動率、典型并行規(guī)模排名等13個維度刻畫了并行應(yīng)用的負載特征,可為典型應(yīng)用篩選提供依據(jù)。關(guān)于應(yīng)用負載特征建模的量化分析已經(jīng)超出了本文的范疇,這里不做展開。
圖9 應(yīng)用負載特征雷達Fig.9 Radar chart of application′s workload characteristics
基于應(yīng)用的作業(yè)特征分析是高性能計算負載分析研究的重要基礎(chǔ)。作業(yè)記賬日志數(shù)據(jù)是開展并行作業(yè)特征分析的數(shù)據(jù)源頭。針對并行作業(yè)特征分析中存在的作業(yè)數(shù)據(jù)識別困難、數(shù)據(jù)格式不統(tǒng)一、目標場景多樣化等問題,本文分別提出了三項關(guān)鍵技術(shù),并集成實現(xiàn)了作業(yè)特征分析工具JobCAT。
通過百萬量級作業(yè)記賬日志數(shù)據(jù)的測試驗證,JobCAT的作業(yè)記賬日志標記率大于95%,這一能力優(yōu)于LLNL的同類工具XDMoD。JobCAT支持7個插件、29項統(tǒng)計報表,可一鍵生成應(yīng)用的作業(yè)特征分析報告,對應(yīng)用負載分析研究具有實用價值。