基于作业记账日志的并行作业特征分析工具 JobCAT*

2022-10-05田鸿运武林平罗红兵莫则尧

国防科技大学学报 2022年5期

田鸿运，刘旭，武林平，罗红兵，莫则尧

(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)。

1 并行作业记账日志数据

1.1 资源管理系统

资源管理系统是超级计算机中的重要基础软件，负责并行作业的资源分配、调度、管理、回收、记录、查询。目前，最为主流的并行作业管理系统有：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为例，介绍并行作业管理系统。

1.2 SLURM并行作业记账日志数据格式

SLURM会为每个作业生成作业记账日志数据，用户可通过sacct查询作业记账数据。SLURM作业记账日志字段如表1所示，sacct支持按起止日期、用户名、作业ID等方式查询，但不支持按应用名称进行查询[15]。

表1 SLURM作业记账日志字段示例

SLURM作业记账日志包括作业号记账日志和作业步记账日志两部分。其中，作业号记账日志的JobID为一个整数，作业步记账日志的JobID在对应作业号记账日志的基础上增加作业步编号后缀。实际分析时需要将作业号记账日志数据和作业步记账日志数据合并才能得到一条完整的记账日志数据信息。

SLURM支持用户使用交互式、预分配式、批处理式三种方式提交并行作业。实际中，用户常使用批处理方式。对于批处理方式提交的作业，作业号记账日志的JobName字段对应于批处理脚本名称，WorkDir字段对应于批处理脚本执行目录，而作业步记账日志中的JobName字段，则对应于作业名称，WorkDir字段对应于作业执行目录。

实际使用中，用户为了区分不同版本的可执行程序文件，常会在可执行程序名称或者作业执行脚本上附带版本号、日期、用户名等信息，或者将可执行程序按照领域内涵进行命名，将可执行程序名称放入批处理作业脚本文件名中，导致同一个应用程序在作业记账日志中的命名并不唯一。

此外，为了加快大规模作业的加载速度，用户常常会组合使用多条作业执行命令，例如将作业投递命令(如：srun)与数据分发命令(如：sbcast)组合使用，导致一个并行作业产生多条作业日志数据，而这些日志记录中可能存在诸如mkdir、rm等辅助功能的命令，导致应用名称易被错误标记。

上述用户行为，导致实际的并行应用名称在作业记账日志中的位置、顺序、大小写没有固定特征。应用名称既可能存在于批处理脚本名称中，也可能存在于某一个作业步的作业名称中。同时，应用名称大小写也可能因为用户命名习惯的差异而各不相同。用户行为的差异，给作业记账日志的应用名称识别标记带来挑战。

2 作业记账日志分析工具JobCAT

2.1 基于关键字模糊匹配的作业日志标记方法

为了应对并行作业记账日志中作业名称多样性给应用名称标记带来的困难，提出一种基于关键字模糊匹配的作业记账日志标记方法，如图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 支持大纲检查的通用作业数据描述抽象模型

为了应对不同作业管理系统记账日志格式的差异，设计了一种支持大纲格式检查的通用作业数据描述模型，如图 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作业管理系统的数据格式转换层支持。

2.3 支持插件定制的柔性可扩展软件架构

为了灵活应对不同场景的作业数据分析需求，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实现了作业记账日志的应用识别标记，满足了工具的跨平台兼容性需求，支持根据业务分析场景开展定制分析。

2.4 JobCAT主要功能介绍

JobCAT的插件清单见表2。目前JobCAT支持7个分析插件，共包含29项统计报表。这些功能插件可以为用户提供超算资源使用分析、内存使用分析、应用特征分析等并行作业数据统计分析支持，进而支撑超算资源调度效率优化、计算节点内存容量配置优化设计、典型业务应用程序筛选等研究，为超算硬件能力建设服务。

表2 JobCAT的插件清单

JobCAT支持通过命令行参数选项，可以动态设置数据分析的起止日期、指定特定的目标用户群体、应用程序集等，并支持根据需要动态加载分析插件。

JobCAT支持命令行与配置文件相结合的配置管理方式，对于系统平台运行环境相关的配置参数，可通过配置文件设置。用户还可在配置文件中灵活指定应用名称关键字列表、作业并行规模分类器、作业运行时长分类器、文档数据格式转换器、用户信息查询缓存表等配置信息。与分析插件、命令行参数一样，配置文件选项也可以按需灵活扩展。

3 实验与分析

3.1 实验环境简介

实验集群包含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三个时间段的作业记账日志开展识别率验证，并使用最后一时间段的作业记账日志开展作业特征统计分析研究。

3.2 作业记账日志识别率验证

实际生产环境下，面向真实物理过程研究的科学计算数值模拟应用往往需要大规模、长时间运行，运行时间短的作业常常是调试作业。调试作业具有运行时间短、占用机时资源少、作业命名随意性强的特点，因此，本文的并行作业特征统计分析主要针对生产型作业。结合实际经验，将调试型作业的运行时长上限设为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作业日志识别率更高的原因。

3.3 作业数据统计分析报告

JobCAT可以支持一键生成作业数据统计分析报告。报告生成的时间开销与作业记账日志数据量成正相关。实验数据表明，对于数十万量级的作业记账日志数据，分析报告生成的时间开销小于5 min。

作业数据统计分析报告包含总体情况分析、计算资源使用情况分析、应用特征分析、作业数据分析。

总体情况分析。包括资源可用率曲线、资源利用率曲线、作业排队情况，它们可以作为超算资源运维管理效率和资源调度效率的衡量指标。资源可用率是衡量系统故障修复能力的重要指标；资源利用率是衡量资源利用率的重要指标；作业排队情况可作为资源调度效率的参考。

计算资源使用情况分析。JobCAT按照用户、团队、科研业务方向分析统计区间内的计算使用情况，给出按照用户、团队、应用程序、并行规则、运行时长等多个维度的计算资源使用明细情况，从而帮助用户服务更有针对性和指向性。

应用特征分析。JobCAT从9个维度开展应用程序作业特征分析，定量刻画了实际系统上的应用程序业务特征，进而为研制系统评测程序提供参考依据。

作业数据分析。JobCAT给出了对内存、IO的资源使用情况的统计分析结果，可以反映实际业务应用对内存、IO资源的真实使用情况，从而为系统容量配置规划提供参考依据。

3.4 并行作业特征分析举例

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个维度刻画了并行应用的负载特征，可为典型应用筛选提供依据。关于应用负载特征建模的量化分析已经超出了本文的范畴，这里不做展开。