技术领域
[0001] 本
发明属于并行程序信息采集技术领域；具体涉及一种数值水池应用特征性能采集和监控系统及其运行方法。
背景技术
[0002] 数值水池的
基础理论是计算
流体力学(CFD)理论，现代计算
流体力学所解决的问题越来越复杂，对于计算能力的要求与日俱增，随着计算
节点及核数的增加，管理开销、通信开销增加，存储
访问争用严重，并行效率下降，并行计算常见的存储墙、并行编程墙，通信墙问题凸现。因此，监测并完善通信效率、通信次数、内存使用率、I/O等和影响性能的指标具有重要的意义。
[0003] 基于集群的计算是并行计算发展的一种必然趋势，它能有效地凝聚计算资源，形成协同的
高性能计算能力，并具有良好的可伸缩性。在集群计算模式下，并行作业的性能监测分析是提高计算效能的一个重要手段，也是并行计算中的一个研究难点，它能够监测复杂并行作业的执行过程，揭示并行作业的执行行为，分析影响执行效率的因素和
瓶颈，为改进和优化并行作业提供依据。
[0004] 现有的并行程序性能分析工具，若按工作方式来分类可以分为监测型和预测型两类。监测型工具通过在程序实际运行时收集性能数据，然后进行统计分析。预测型工具要求建立一个数学模型，用若干参数来表示影响程序性能的因素，然后通过对程序结构进行静态分析，估计这些参数的值，进而预测程序性能。由于这些参数与
操作系统、编译器等许多因素有关，因此要建立一个数学模型来预测程序的性能非常困难。若按实现手段来划分，则有事件抽样(event sampling)、
硬件事件记录器和
软件事件记录器等方法。其中事件抽样方法可以产生最小的数据集，但不便于监测和显示整个程序的执行过程及其细节。如果没有相应硬件监测部件的支持，事件抽样的干扰也会比较大。硬件事件记录器方法虽然对程序执行行为的干扰较少，但它依赖于硬件制造商的设计，不方便用户根据自己的播求进行取舍。软件事件记录器方法是目前广泛使用的一种软件监测方法。具体实现起来有两种方式:一种是使
系统软件附带监测功能，另一种是在
应用软件中使用软件事件记录器。第一种方案是使操作系统和通讯库等具有监测功能。这对用户是非常方便的，因为可以不必
修改程序代码而获得性能数据，然而，这需耍系统软件商的参与，而且不便为用户提供在程序的不同部分
开关监控器的简单方法。
发明内容
[0005] 由于数值水池的核心求解器对于并行计算能力的要求与日俱增，但是一昧的增加核数，会导致通信次数增加，进而达到性能瓶颈，计算效率下降，为了能够设计出与计算规模相匹配的计算资源分配方案，对运算过程中的虚拟试验计算实施监控和性能信息的采集具有十分重要的意义；
[0006] 针对以上分析，本发明提供了一种数值水池应用特征性能采集和监控技术，统计除监测每次虚拟试验的性能数据之外，同时采集每个作业的执行次数和累计耗费时间，它主要反映的是不同过程运行的时间、各种不同类型的通信花费的时间及执行次数和各处理器节点运行的时间等。
[0007] 本发明通过以下技术方案实现：
[0008] 一种数值水池应用特征性能采集和监控系统，所述系统包括数值水池应用特征性能采集和监控系统100、应用性能基准线管理模
块101和应用性能分析报告模块102，所述应用性能基准线管理模块101和应用性能分析报告模块102均将
信号传输至数值水池应用特征性能采集和监控系统100；
[0009] 所述应用性能基准线管理模块101包括管理员设置性能基准线模块110、估算作业运行时长模块111和作业运行状况分析模块112，所述作业运行状况分析模块112将
信号传输至管理员设置性能基准线模块110，所述管理员设置性能基准线模块110将信号传输至估算作业运行时长模块111；
[0010] 所述应用性能分析报告模块102包括应用性能统计CPU利用率模块113、应用性能统计GPU利用率模块114、应用性能统计MEM利用率模块115、应用性能统计SWAP利用率模块116、应用性能统计网络收发速率模块117、应用性能统计磁盘读写速率模块118及基准线曲线对比图模块119；
[0011] 应用性能统计CPU利用率模块113为为监测应用在CPU计算资源上的利用率，应用性能统计GPU利用率模块114为监测应用在GPU计算资源上的利用率，应用性能统计MEM利用率模块115为监测用户提交并行程序时，使用内存空间的合理性，应用性能统计SWAP利用率模块116为用户展示当前或历史作业的
指定时间内该版本应用Swap的平均值，最大值，最小值，以确保虚拟内存的使用
频率，应用性能统计网络收发速率模块117，应用性能统计磁盘读写速率模块118展示当前或历史作业的指定时间内该版本应用磁盘读/写速率的平均值，最大值，最小值，基准线曲线对比图模块119方便用户针对8项信息对程序进行有目的修改。
[0012] 利用上述数值水池应用特征性能采集和监控系统的运行方法，所述运行方法包括作业提交步骤、作业基本信息和状态获取步骤，利用所述管理员设置性能基准线模块110的作业提交步骤具体为：
[0013] 步骤110.1：从前端页面获取参数后，首先判断是否所有必填项都已填写完毕；
[0014] 步骤110.2：如果参数全部填写完整，则分别判断提交作业所必须的三个shell脚本都已正确编写：app.sh、en.sh和submit.sh；
[0015] 步骤110.3：当步骤110.2已满足要求，则解析调度系统参数，所有模板参数以“--”开头，其中job-name为作业名称，用于后续作业目录名的生成；
[0016] 步骤110.4：获取作业目录：在submit.sh中，当调度系统参数中存在workdir时，其值即为作业目录的根目录；否则获取用户home目录为作业目录；
[0017] 步骤110.5：所有参数设置完毕后，会执行submit.sh脚本，为启动作业调度系统PBS做脚本预处理执行准备；
[0018] 步骤110.6：PBS作业调度系统相关参数解析完毕之后，满足提交作业基本条件；
[0019] 步骤110.7：执行qsub指令，将作业分配到作业调度系统当中执行；
[0020] 步骤110.8：建立
数据库的t_job表，并将作业id，作业名称，作业目录，应用参数，调度系统参数写入t_job表中；
[0021] 步骤110.9：该作业运行信息写入数据库后，本次提交作业操作完毕。
[0022] 进一步的，所述作业基本信息和状态获取步骤具体为：
[0023] 步骤112.1：设置采集时间段
阈值，按照集群名称读取一次作业信息；
[0024] 步骤112.2：执行qstat-f命令，按照队列id获取到当前调度系统中的作业，判断是否有返回值；
[0025] 步骤112.3：解析返回值；
[0026] 步骤112.4：将解析完成的返回值传递给数据库表t_job_filter，同时更新信息；
[0027] 步骤112.5：创建t_job_state表，用于存储作业状态变更时间；
[0028] 步骤112.6：获取集群信息，按照集群名称采集作业状态；
[0029] 步骤112.7：获取当前尚未结束的作业：从t_job_state表中获取；执行qstat命令，将两种结果合并更新；
[0030] 步骤112.8：执行qstat-a命令，获取当前调度系统中的所有作业的信息，解析返回值，获取作业状态，更新t_job_state表；
[0031] 步骤112.9：对比之前获取的尚未结束的作业信息和已经更新的作业信息，如果有剩余未更新的作业，执行qstat-a{作业号id}进行查询；
[0032] 步骤112.10：完成作业基本信息和状态信息的获取和更新。
[0033] 进一步的，基于应用性能分析报告模块102模块采集的指标前，在集群中各个
服务器节点上部署pgatherd组件125，在登录节点上部署nats组件121、tower组件122、pmonitor组件123和mysql组件124组件，所述pgatherd组件125的
数据采集和数据加工步骤如下：
[0034] 步骤102.1：pgatherd组件125从系统中获取服务器cpu数据，
整理后将数据发送至nats组件121；
[0035] 步骤102.2：tower组件122主动从nats组件121中获取数据；
[0036] 步骤102.3：在pmonitor组件123中开启定时线程，按照每小时、每分钟、每天计算；
[0037] 步骤102.4：通过调用基准线
接口，在展示8项性能指标的同时，每次作业提交之后，读取数据库中存储的相似度最高的基准作业，并将基准线以折线的形式展示在本次的性能数据展示中。
[0038] 进一步的，所述步骤102.2具体为：
[0039] 步骤102.2.1：tower组件122从nats组件121中获取到pgatherd组件125采集出来的原始数据，将数据汇入rawFlow组件131中；
[0040] 步骤102.2.2：由rawFlow组件131将采集的性能数据传输到filterCore组件132中，其中core是一个对数据进行加工处理的代码块，filterCore组件132过滤出需要的数据；
[0041] 步骤102.2.3：由filterCore组件132将数据传输到collectCore组件133中；collectCore组件133将性能数据进行整理加工，使其成为易读易更新的标准数据集；
[0042] 步骤102.2.4：由collectCore组件133计算完成之后，将数据写入Mysql数据库中。
[0043] 本发明的有益效果是：
[0044] 1、能够对数值水池的各种应用实行有效的监控和性能数据采集，同时不会对运行的程序有任何速率影响。
[0045] 2、能够有效估算初数值水池的某个应用执行时间，方便用户按照自身计算资源进行合理调整参数。
[0046] 3、能够设置正确有效的基准线，在应用计算过程中，通过应用性能分析报告模块采集的性能数据与基准线进行对比，能够给用户提供正确提升
算法优化的方向。
[0047] 快速、正确的采集影响数值水池应用运行过程中的8项指标：CPU利用率、GPU利用率、MEM利用率、SWAP利用率、网络收\发效率、磁盘读写效率，为数值水池应用效率的提高提供技术支持和改进方向建议
附图说明
[0048] 图1本发明结构示意图；
[0049] 图2本发明作业提交流程示意图；
[0051] 图4本发明作业状态获取流程图；
[0052] 图5本发明应用分析报告102模块内部实现流程图；
[0053] 图6本发明121模块与122模块内部数据交互图。
具体实施方式
[0054] 下面将结合本发明
实施例中的附图对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0055] 实施例1
[0056] 一种数值水池应用特征性能采集和监控系统，所述系统包括数值水池应用特征性能采集和监控系统100、应用性能基准线管理模块101和应用性能分析报告模块102，所述应用性能基准线管理模块101和应用性能分析报告模块102均将信号传输至数值水池应用特征性能采集和监控系统100；
[0057] 所述应用性能基准线管理模块101包括管理员设置性能基准线模块110、估算作业运行时长模块111和作业运行状况分析模块112，所述作业运行状况分析模块112将信号传输至管理员设置性能基准线模块110，所述管理员设置性能基准线模块110将信号传输至估算作业运行时长模块111；
[0058] 所述应用性能分析报告模块102包括应用性能统计CPU利用率模块113、应用性能统计GPU利用率模块114、应用性能统计MEM利用率模块115、应用性能统计SWAP利用率模块116、应用性能统计网络收发速率模块117、应用性能统计磁盘读写速率模块118及基准线曲线对比图模块119；
[0059] 应用性能统计CPU利用率模块113为为监测应用在CPU计算资源上的利用率，应用性能统计GPU利用率模块114为监测应用在GPU计算资源上的利用率，应用性能统计MEM利用率模块115为监测用户提交并行程序时，使用内存空间的合理性，应用性能统计SWAP利用率模块116为用户展示当前或历史作业的指定时间内该版本应用Swap的平均值，最大值，最小值，以确保虚拟内存的使用频率，应用性能统计网络收发速率模块117，应用性能统计磁盘读写速率模块118展示当前或历史作业的指定时间内该版本应用磁盘读/写速率的平均值，最大值，最小值，基准线曲线对比图模块119方便用户针对8项信息对程序进行有目的修改。
[0060] 利用上述数值水池应用特征性能采集和监控系统的运行方法，所述运行方法包括作业提交步骤、作业基本信息和状态获取步骤，利用所述管理员设置性能基准线模块110的作业提交步骤具体为：提交作业模块实施的主要流程如图2所示，
[0061] 步骤110.1：从前端页面获取参数后，首先判断是否所有必填项都已填写完毕；
[0062] 步骤110.2：如果参数全部填写完整，则分别判断提交作业所必须的三个shell脚本都已正确编写：app.sh、en.sh和submit.sh；其中，app.sh中包含了作业运行所必需的linux执行命令，en.sh包含了环境参数/库文件导入命令、submit.sh包含了作业调度系统PBS提交作业的指令格式和命令；
[0063] 步骤110.3：当步骤110.2已满足要求，则解析调度系统参数，所有模板参数以“--”开头，其中job-name为作业名称，用于后续作业目录名的生成；
[0064] 步骤110.4：获取作业目录：在submit.sh中，当调度系统参数中存在workdir时，其值即为作业目录的根目录；否则获取用户home目录为作业目录；shell脚本中文件路径接口格式书写如下：Basedir/jobs/{job-name_当前时间}；
[0065] 步骤110.5：所有参数设置完毕后，会执行submit.sh脚本，为启动作业调度系统PBS做脚本预处理执行准备；本步骤可以解析出作业名称、作业目录、核数、是否需要执行此脚本等命令；
[0066] 步骤110.6：PBS作业调度系统相关参数解析完毕之后，满足提交作业基本条件；此步骤将通过shell脚本解析与作业程序相关的命令集合，保证作业按照算法逻辑依次执行；
[0067] 步骤110.7：执行qsub指令，将作业分配到作业调度系统当中执行；
[0068] 步骤110.8：建立数据库的t_job表，并将作业id，作业名称，作业目录，应用参数，调度系统等参数写入t_job表中；
[0069] 步骤110.9：该作业运行信息写入数据库后，本次提交作业操作完毕。由管理员设置某次作业为基准作业，在前台页面输入作业ID后，可在数据库中查询到相关作业信息。如设置了基准作业，则在t_job表中添加一个is_base字段用于区分是否是基准线作业：altertable t_job add`is_base`tinyint(4)DEFAULT'0'；
[0070] 设置基准线逻辑实现完毕。
[0071] 将用户提交的与计算时长相关作业参数信息(网格数量、核数、时间步、
雷诺数等)生成xml文件。每次作业启动后，本发明会读取xml文件中的内容。在数据库中以应用名称app_id查询到所有此id的基准线作业信息。读入数据库中影响时长的参数信息，与本次的xml进行对比，进行无量纲化后，通过欧式距离计算方法，求得参数相似度最高的一组基准线作业。以作业id名称work_id查询数据库中该作业信息，并返回运行时长，该运行时间即为估算的时长。估算的时间与实际运行时间展示在同一个功能模块页面上。
[0072] 进一步的，所述作业基本信息和状态获取步骤具体为：
[0073] 步骤112.1：设置采集时间段阈值，通常设置5秒按照集群名称读取一次作业信息；
[0074] 步骤112.2：执行qstat-f命令，按照队列id获取到当前调度系统中的作业，判断是否有返回值；
[0075] 步骤112.3：解析返回值，从中获取作业id，作业名称，cpu等信息；
[0076] 步骤112.4：将解析完成的返回值传递给数据库表t_job_filter，同时更新信息；
[0077] t_job_filter设计如下：
[0078] CREATE TABLE`t_job_filter`(
[0079] `id`int(11)NOT NULLAUTO_INCREMENT，
[0080] `job_id`varchar(100)NOT NULL，
[0081] `cluster_id`varchar(100)NOT NULL，
[0082] `done`tinyint(1)DEFAULT NULL，
[0083] `user`varchar(32)DEFAULT NULL，
[0084] `portal_user`varchar(32)DEFAULT NULL，
[0085] `portal_id`varchar(32)DEFAULT NULL，
[0086] `account`varchar(32)DEFAULT NULL，
[0087] `state`varchar(32)DEFAULT NULL，
[0088] `original_state`varchar(32)DEFAULT NULL，
[0089] `part`varchar(32)DEFAULT NULL，
[0090] `name`varchar(128)DEFAULT NULL，
[0091] `nodes`text，
[0092] `nodes_num`int(11)DEFAULT NULL，
[0093] `submit`datetime DEFAULT NULL，
[0094] `start`datetime DEFAULT NULL，
[0095] `end`datetime DEFAULT NULL，
[0096] `suspend_sec`int(11)DEFAULT NULL，
[0097] `ncpus`int(11)DEFAULT NULL，
[0098] `mem`bigint(20)DEFAULT NULL，
[0099] `wtime`int(11)DEFAULT NULL，
[0100] `timestamp`datetime DEFAULT NULL，
[0101] PRIMARY KEY(`id`)，
[0102] UNIQUE KEY`job_cluster`(`job_id`，`cluster_id`)
[0103] )；
[0104] 步骤112.5：创建t_job_state表，用于存储作业状态变更时间；history_status字段即为历史作业状态信息，格式为{`作业状态`:[时间1，时间2，时间3]，`作业状态2`：[时间4，时间5]……}；设计如下：
[0105] CREATE TABLE`t_job_state`(
[0106] `id`int(11)NOT NULLAUTO_INCREMENT，
[0107] `job_id`varchar(100)NOT NULL，
[0108] `cluster_id`varchar(100)NOT NULL，
[0109] `current_state`varchar(20)DEFAULT NULL，
[0110] `original_state`varchar(20)DEFAULT NULL，
[0111] `history_status`mediumtext，
[0112] `history_original_state`mediumtext，
[0113] `last_refresh_time`bigint(20)DEFAULT NULL，
[0114] `is_terminated`tinyint(1)DEFAULT'0'，
[0115] PRIMARY KEY(`id`)，
[0116] UNIQUE KEY`job_cluster`(`job_id`，`cluster_id`)
[0117] )；
[0118] 步骤112.6：获取集群信息，按照集群名称采集作业状态；
[0119] 步骤112.7：获取当前尚未结束的作业：从t_job_state表中获取；执行qstat命令，将两种结果合并更新；
[0120] 步骤112.8：执行qstat-a命令，获取当前调度系统中的所有作业的信息，解析返回值，获取作业状态，更新t_job_state表；
[0121] 步骤112.9：对比之前获取的尚未结束的作业信息和已经更新的作业信息，如果有剩余未更新的作业，执行qstat-a{作业号id}进行查询；
[0122] 步骤112.10：完成作业基本信息和状态信息的获取和更新。
[0123] 作业信息采集并存入数据库后，可以方便用户对自己作业进行查询，同时也为基准线的设置提供
支撑。
[0124] 进一步的，所述应用性能分析报告模块102包括应用性能统计CPU利用率模块113、应用性能统计GPU利用率模块114、应用性能统计MEM利用率模块115、应用性能统计SWAP利用率模块116、应用性能统计网络收发速率模块117、应用性能统计磁盘读写速率模块118及基准线曲线对比图模块119，基于以上模块采集的指标前，首先设计125pgatherd组件。采用了异步处理
框架以及可扩展、可配置的模块化框架。为使得pgatherd组件125可以以低负载的方式高效的采集数据，pgatherd组件125基于libuv异步框架进行实现。libuv强制使用异步的，事件驱动的编程
风格。它的核心工作是提供一个event-loop，还有基于I/O和其它事件通知的回调函数。在pgatherd组件125组件中每一个监控项都被定义为一个监控模块，每一个模块都会实现模块定义的标准init、handler、cleanup接口；当libuv的异步架构系统初始化时，每个模块会将其关心的监控事件/驱动注册到事件循环中(如读取系统文件)。每次事件循环中收到操作系统的返回动作，便会触发模块的handler回调，进行具体监控数据的格式化、打包、发送等行为(这也是异步的)。在以标准回调接口形式定义模块划分的基础上，将模块编译为系统动态库，并在pgatherd组件125内实现按配置文件动态加载的机制，这样pgatherd组件125便实现了模块的动态加载和可配置化。
[0125] pgatherd组件125本身不具备任何监控能力，只是一个数据采集模块的管理框架这些系统信息数据收集的功能全部实现在模块的回调处理函数中。在集群中各个服务器节点上部署pgatherd组件125，在登录节点上部署nats组件121、tower组件122、pmonitor组件123和mysql组件124组件，所述pgatherd组件125的数据采集和数据加工步骤如下：
[0126] 步骤102.1：pgatherd组件125从系统中获取服务器cpu数据，整理后将数据发送至nats组件121；数据采集过程都是由模块完成的，每个模块按照配置的时间间隔，采集对应的性能数据，并且生成一个完成的JSON格式的文档；对于每个模块生成的文档，都包含如下通用字段：
[0127]
[0128] 其中，hostid来自于配置文件，如果配置文件没有指定，则从/etc/machine-id或者/sys/class/dmi/id/product_uuid中依次取值。timestamp是数据的采集时间，格式是milliepoch。以CPU性能采集为例，格式如下：
[0129]
[0130] 步骤102.2：tower组件122主动从nats组件121中获取数据；
[0131] 步骤102.3：在pmonitor组件123中开启定时线程，按照每小时、每分钟、每天计算；tower组件122中记录了集群下各个节点的性能数据，那么集群性能即为集群下所有节点的性能数据的平均值。由pmonitor组件123计算每5分钟的CPU、MEM、SWAP等利用率数据的平均值，并以折线图的形式反馈给用户；
[0132] 步骤102.4：通过调用基准线接口，在展示8项性能指标的同时，每次作业提交之后，读取数据库中存储的相似度最高的基准作业，并将基准线以折线的形式展示在本次的性能数据展示中；方便用户与标准算例进行对比，进而提高算法的扩展性和准确性。
[0133] 进一步的，所述步骤102.2具体为：
[0134] 步骤102.2.1：tower组件122从nats组件121中获取到pgatherd组件125采集出来的原始数据，将数据汇入rawFlow组件131中；
[0135] 步骤102.2.2：由rawFlow组件131将采集的性能数据传输到filterCore组件132中，其中core是一个对数据进行加工处理的代码块，filterCore组件132过滤出需要的数据；(pgatherd组件中有许多模块，对于8项数据，只需要cpu、gpu、mem等信息)；
[0136] 步骤102.2.3：由filterCore组件132将数据传输到collectCore组件133中；collectCore组件133将性能数据进行整理加工，使其成为易读易更新的标准数据集；
[0137] 步骤102.2.4：由collectCore组件133计算完成之后，将数据写入Mysql数据库中。
[0138] (一)应用性能基准线管理模块
[0139] 应用性能基准线管理模块由三个子模块构成：管理员设置性能基准线模块、估算作业运行时长模块和作业运行状况分析模块。应用性能分析模块可以根据从系统运行状况和作业运行信息模块中获得的大量运行状态数据，针对客户的应用运行状况提供清晰明了的定性和定量分析，为优化应用运行提供准确的数据参考。
[0140] 1、管理员设置性能基准线模块
[0141] 管理员对数值水池某个虚拟试验设置应用性能基准线，并以此为参照标准，对普通用户提交的作业性能曲线进行对比分析，使用户能够直观看到当前应用运行性能曲线的增幅变化，方便用户对应用进行调试和优化。
[0142] 2、估算作业运行时长模块
[0143] 管理员按照某个虚拟试验的基准线设置之后，分别将多个不同问题规模范围的算例有效执行时间写入数据库。当普通用户启动作业之后，可以判断出本次算例最少需要多少时间，用户可调整工况参数以满足自身需求。
[0144] 3、作业运行状况分析模块
[0145] 作业运行状况分析模块负责按照用户指定的约束条件，对满足条件的作业运行分析。主要包含：作业开始时间、作业结束时间、作业运行状态信息、作业运行时计算节点使用个数、作业运行时长。本发明按照不同的任务提交统计作业数量，生成作业运行统计报告，并将其变化情况以曲线图的形式进行显示。
[0146] (二)应用性能分析报告模块
[0147] 应用性能分析报告模块详细展示了单个应用的性能数据，以应用为维度显示了应用各个版本之间的性能数据等信息的差别。该模块通过采集PBS作业系统中的作业信息，
可视化展示当前用户执行或历史作业的性能数据。
[0148] 该功能主要分解为：
[0149] 应用性能统计表-CPU
[0150] 为监测应用在CPU计算资源上的利用率，本模块可以展示当前或历史作业的指定时间内该版本应用CPU利用率的平均值，最大值，最小值。
[0151] 应用性能统计表-GPU
[0152] 为监测应用在GPU计算资源上的利用率，展示当前或历史作业的指定时间内该版本应用GPU利用率的平均值，最大值，最小值。
[0153] 应用性能统计表-Mem
[0154] 为监测用户提交并行程序时，使用内存空间的合理性。本模块可以展示当前或历史作业的指定时间内该版本应用内存使用率的平均值，最大值，最小值，向用户进行信息反馈。
[0155] 应用性能统计表-Swap
[0156] 为保证尽量减少物理内存的使用，本模块为用户展示当前或历史作业的指定时间内该版本应用Swap的平均值，最大值，最小值，以确保虚拟内存的使用频率。
[0157] 应用性能统计表-磁盘读/写速率
[0158] 为方便用户本地I/O的读写次数和效率，本模块展示当前或历史作业的指定时间内该版本应用磁盘读/写速率的平均值，最大值，最小值。将性能数据信息反馈用户，减少并行程序的冗余读写。
[0159] 应用性能统计表-网络收/发速率
[0160] 通信次数及通信效率是数值水池应用执行效率的重要衡量指标，本模块用于展示当前或历史作业的指定时间内该版本应用网络收/发速率的平均值，最大值，最小值，方便用户按照自身需要，修改算法或数据结构，达到最小化通信次数的目的。
[0161] 基准线数据对比曲线图
[0162] 通过从数据库中获取作业运行期间平均基准线数据，用以和当前或历史作业的指定时间内该版本应用的性能数据信息做对比，方便用户针对8项信息对程序进行有目的修改，同时减少开发时间，有效提高程序的可用性和扩展性。
