CN106445781A - 基于消息传递的hpc大规模并行程序异常自动监测及软硬件原因判断的检测系统 - Google Patents

基于消息传递的hpc大规模并行程序异常自动监测及软硬件原因判断的检测系统 Download PDF

Info

Publication number
CN106445781A
CN106445781A CN201610854431.3A CN201610854431A CN106445781A CN 106445781 A CN106445781 A CN 106445781A CN 201610854431 A CN201610854431 A CN 201610854431A CN 106445781 A CN106445781 A CN 106445781A
Authority
CN
China
Prior art keywords
node
heartbeat
message
module
work
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610854431.3A
Other languages
English (en)
Other versions
CN106445781B (zh
Inventor
刘轶
张国振
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kaixi Beijing Information Technology Co ltd
Original Assignee
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN201610854431.3A priority Critical patent/CN106445781B/zh
Publication of CN106445781A publication Critical patent/CN106445781A/zh
Application granted granted Critical
Publication of CN106445781B publication Critical patent/CN106445781B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，该系统克服了集中式检测机制性能开销大，扩展性差的问题，通过对消息传递行为的异常监测，被动心跳机制为每个节点上的工作进程设置消息监控计时器，当消息行为发生异常时，才会向主控节点发送心跳消息，而在正常情况下，并不用发送心跳，从而避免了对网络资源的占用，扩展性也不会因此受限，利用可疑事件定位机制，只在需要的时候进行状态检查，本发明对MPI程序的执行所造成的性能开销可以忽略不计，易于扩展支持高性能计算机上的大规模并行应用程序在运行和调试阶段的运行错误软硬件原因的判断。

Description

基于消息传递的HPC大规模并行程序异常自动监测及软硬件 原因判断的检测系统
技术领域
本发明涉及一种应用于HPC大规模并行程序的异常检测器、以及对于所述HPC大规模并行程序运行失败的原因进行软硬件判断的检测系统。更特别地说是一种基于消息传递采用被动心跳机制自动触发异常报警，并通过可疑事件定位机制进行异常软硬件原因检测和判定的检测系统。
背景技术
高性能计算(high performance computing，HPC)的规模庞大，结构复杂，计算能力强大，从了解蛋白质折叠过程到预测短期和长期的气候模式，大规模并行HPC模拟成为人们首选的工具，这些应用程序可以运行详细的数值模拟，为现实世界建模，使科学和工程领域的突破成为可能。
随着HPC向Exascale(百亿亿次，E级)计算推进，计算能力显著提高的同时，由于规模的增大，部件的增多，系统结构更加的复杂，运行其上的HPC应用程序在运行过程失败的概率也会增多。
HPC应用程序具有大规模和并行的特点，它可能会运行在数以百计数以千计的节点上，数以万计数以十万计的处理器核上。导致程序出错的原因可能来源于软件错误，也可能来源于硬件系统故障。而在应用程序级别，可能会有相同或者相似的程序行为。加之错误在程序执行过程中的传播。开发人员和调试人员以及用户很难判断。
HPC领域的科学计算程序在执行过程中发生失败，相关研究表明，高性能计算机程序执行失败的各项原因中，程序本身的软件错误和硬件系统的故障占了其中绝大部分，程序软件本身的错误主要是由于程序的错误引起的，按照对程序执行过程的影响可以分为失败-终止(fail-stop)和失败-非终止(fail-nonstop)错误，失败-终止是指程序错误导致了程序的异常退出，而失败-非终止是指程序错误只是对程序的变量或者数据产生影响，而没有使程序终结，程序能够执行下去，但最终产生的计算结果很可能是不正确的。而大规模并行程序的错误有些只有在大规模的程序运行过程中才能显现出来。
HPC系统的硬件系统发生故障，可能会导致瞬时故障，导致数据损坏的发生，当数据损坏发生在控制变量上，则会影响程序的正常执行，导致程序的非正常终结，而若发生在非控制变量上，则会改变数据的值，使得计算结果不正确。也可能会发生永久性故障，那么该节点上运行的MPI(messages passing interface，消息传递)工作进程显然会异常退出。而在应用级，用户可能无法及时察觉到这些异常情况。
另一方面，随着HPC规模向E级推进，可靠性的问题更加突出。虽然随着科技和工艺技术的不断提高，单个电子器件的MTBF(mean time between failures，平均无故障运行时间)可以高达106小时，但对于现有的P级(Petascale，千兆级)系统来说，可能有数万个甚至数十万个处理器，系统的整体MTBF也只能达到1～100小时。对于那些运行规模很大，运行时间很长的HPC应用程序来说，在程序执行过程中发生硬件系统故障是在所难免的。
软件错误和硬件故障都有可能导致程序进程的非正常终结或者导致错误的计算结果，从程序行为的角度来看，两者导致的结果并没有本质的区别。
由于HPC应用运行在大规模的节点上，发生失败可能会发生在任意的时间点，任意的节点上，用户并不能确定，甚至用户并不能察觉到这种失败，也不能确定异常发生的时间点，位置，以及根源。这给HPC大规模并行程序的调试以及生产过程中的故障诊断带来很大的难度。
发明内容
为了确定出HPC大规模并行程序执行失败的根源原因，本发明的目的是提供一种基于消息传递的程序异常自动监测及软硬件原因判别的检测系统，该检测系统利用科学计算应用程序中普遍存在的消息传递，采用被动心跳机制，实现了HPC大规模并行程序执行过程中异常的自动报警并触发可疑事件的定位；一方面克服了采用集中式的心跳机制检查系统硬件状态需要进行周期性地检测，开销大，可扩展性差的问题；另一方面实现了HPC大规模并行程序执行过程中异常的自动报警和检测，准确定位硬件故障，同时为软件的错误根源定位提供最具可能性的若干候选项。本检测系统提高了程序调试和问题诊断的效率和准确度，降低了时间开销和资源浪费。
本发明检测系统由服务初始化模块(1)、节点信息采集模块(2)、本地消息传递监测模块(3)、节点内心跳管理模块(4)、心跳检测模块(5、6)、可疑事件检测定位模块(7、8)、报告生成模块(9)和服务关闭模块(10)组成。
称HPC程序MPI进程运行所在的节点为工作节点，选择MPI rank为0的进程所在的节点为主控节点。主控节点上如果运行有MPI工作进程，那么该节点即是主控节点也是一个工作节点。其中服务初始化模块、本地消息传递检测模块、节点内心跳管理模块位于所有的工作节点上，节点信息采集模块、报告生成模块和服务关闭模块位于主控节点上。心跳检测模块分为SERVER端和CLIENT端两部分，SERVER端位于主控节点上，CLIENT端位于工作节点上。可疑事件检测定位模块也分为SERVER端和CLIENT端两部分，CLIENT端位于主控节点上，而在每个工作节点上都有一个SERVER端。
服务初始化模块在HPC程序执行的开始阶段分别启动三个服务进程，分别是心跳检测服务，该服务即是主控节点上的心跳检测模块的SERVER端；可疑事件检测定位服务，即是位于工作节点上的可疑事件检测定位模块的SERVER端；本地心跳管理服务，即是位于每个工作节点上的节点内心跳管理模块。
节点信息采集模块收集HPC程序运行时的进程相关信息及各进程运行所在的结点的相关信息，包括MPI进程的进程Id，节点名，IP地址等，为后面的可疑事件检测定位模块确定需要检查的节点列表。
本地消息传递监测模块监测本地工作进程中的消息传递操作，当存在消息传递发生时，生成一个请求重置计时器的通知，通过计时器超时警报该进程中消息传递的异常行为。
节点内心跳管理模块对同一个节点上运行的隶属于同一个HPC程序的多个工作进程的状态进行监测和管理，接收工作进程发送来重置计时器请求，重置计时器，当计时器超时时，向主控节点的心跳检测模块SERVER端发送一条心跳消息。
心跳检测模块包括SERVER端和CLIENT端两部分，之间采用TCP的方式建立socket连接进行消息的发送和接收。SERVER端位于主控节点上，等待接收来自各个工作节点的心跳消息，设定一个程序行为异常报警的Threshold，CLIENT端以函数调用的方式被实现，由各个工作节点上的本地心跳管理服务调用，向SERVER端发送心跳消息。SERVER端接收到的心跳消息数量超过Threshold时判定当前程序执行过程中存在可疑事件发生导致程序行为异常，从而触发可疑事件检测定位。
可疑事件检测定位模块也分为SERVER端和CLIENT端两部分，之间采用UDP的方式建立socket连接进行消息的发送和接收。SERVER端位于每个工作节点上，即由服务初始化模块在程序开始阶段启动的可疑事件检测定位服务，等待接收来自CLIENT端的检测请求并回复响应信息。CLIENT端位于主控节点上，以函数调用的方式实现，当触发可疑事件检测定位时，采用轮询地方式，向每个工作节点发送检测请求，获取各个节点的硬件系统状态。
报告生成模块记录可疑事件检测定位的结果，内容包括节点名、节点IP以及硬件系统状态alive或者dead等。当存在节点状态为dead时，判定导致HPC程序执行失败的原因为硬件系统故障，否则为程序错误引起的。
服务关闭模块将在程序执行结束后对服务初始化模块所启动的三个服务即心跳检测服务、可疑事件检测定位服务和本地心跳管理服务进行清理。原因是在初始化阶段，为了避免对HPC程序执行的影响，将这三个服务以独立进程的方式而非MPI进程的方式运行。所以在HPC程序结束后，这些独立运行的服务进程并不会随之自动终结。
本发明的优点：
①本发明方法考虑到HPC应用程序中广泛存在的消息传递，大部分以MPI的形式实现。从程序执行过程中程序行为异常的角度出发，通过监测消息传递的异常来发现程序执行的异常，自动进行可疑事件的警报，克服了大规模并行程序由于分布式地运行在多核多CPU多节点上，执行过程中错误难发现，易疏漏的问题。
②本发明方法的被动心跳检测机制提供对可疑事件的感知，该机制实现了程序执行异常情况下的心跳信息的产生、发送和接收，与集中式的心跳检测机制相比，不需要周期性地频繁检测各个节点硬件系统的运行状态，不但减少了不必要的时间开销和资源浪费，而且具有更好的可扩展性，适用于更大规模的并行程序。
③本发明方法通过可疑事件定位轮询地检测程序运行所在的节点的硬件系统状态，区分开导致程序运行失败的硬件系统原因和软件错误原因。并针对相应的硬件系统原因检测出精确的节点位置，针对软件错误原因检测出接近错误根源的进程或代码区，大大降低了程序调试和问题诊断的复杂度和耗费的精力。
④本发明方法整体以库的方式实现，通过函数调用的形式，添加到HPC程序中，对源程序只做少量修改。服务进程以独立进程而非MPI进程的方式启动，避免了对HPC程序执行过程的干扰，方案实现对HPC程序性能的影响很小可以忽略不计。
附图说明
图1是应用于HPC大规模并行程序的异常检测器的异常检测的原理示意图。
图2是本发明检测系统的结构框图。
图3是本发明服务初始化模块工作流程示意图。
图4是本发明节点信息采集模块工作流程图。
图5是本发明本地消息传递监测模块工作流程示意图。
图6是本发明节点内心跳管理模块工作流程示意图。
图7是本发明心跳检测模块工作流程示意图。
图8是本发明可疑事件检测定位模块工作流程示意图。
图9是本发明报告生成模块工作流程示意图。
图10是本发明服务关闭模块工作流程示意图。
图11是添加本发明方法前后Linpack性能开销对比。
图12是多节点上添加本发明方法前后对Linpack性能的影响。
图13是Linpack运行时间随问题规模的变化。
具体实施方式
下面将结合附图和实施例对本发明做进一步的详细说明。
本发明基于HPC科学计算应用执行过程中进程间普遍存在的消息传递，通过被动的心跳检测机制感知程序执行过程中异常情况，触发可疑事件检测，对可疑事件发生的位置进行定位，从而区分程序执行失败是由硬件故障引起的还是由软件错误引起的，帮助开发人员或用户自动排除硬件因素，以及有针对性地进行软件错误查找、软件调试和根源分析。
参见图1所示，本发明实现异常检测的方法是借助HPC应用中的消息传递，HPC中的消息传递大部分是以MPI的方式实现的。MPI程序以多进程的并行运行在大规模节点上，进程之间通过消息传递的方式进行通信。无论是程序错误还是硬件系统故障都有可能导致进程的阻塞、死锁或非正常终结等问题。一方面当程序执行在某个节点或某个进程发生失败时并不易被察觉，有时候当异常被发现时距离异常产生已经很长一段时间；另一方面无法从程序行为的角度区分，程序执行过程中发生失败的原因到底是由硬件故障引起的还是由系统软件错误引起的，如果每次怀疑程序执行过程存在异常时，都去手动查询程序运行在哪些节点上，以及节点当前的状态，很明显会给大规模并行程序的调试和错误的诊断带来很大的麻烦。本发明方法能够对程序执行过程中的可疑事件自动报警并进行自动检测，协助区分软件错误、硬件故障的检测。由程序错误或硬件系统故障引起的程序失败会体现在程序的异常行为上，而程序的异常行为又进一步体现在程序执行过程中的消息传递上，异常的消息传递触发检测器对当前节点的硬件系统状态进行检查，从而获取必要的信息。
参见图2所示，本发明设计了一种基于消息传递的程序异常自动监测及软硬件原因判别系统，该系统由服务初始化模块1、节点信息采集模块2、本地消息传递监测模块3、节点内心跳管理模块4、心跳检测模块、可疑事件检测定位模块、报告生成模块9和服务关闭模块10组成。其中，心跳检测模块分为SERVER端心跳检测模块6和CLIENT端心跳检测模块5；可疑事件定位模块分为SERVER端可疑事件定位模块8和CLIENT端可疑事件定位模块7。
服务初始化模块1
本发明的服务初始化模块1用来初始化启动三个服务进程，即心跳检测服务、可疑事件定位服务和本地心跳管理服务，参见图3所示，给出了服务初始化模块1的工作流程：
在本发明中，MPI应用程序执行过程中能够获得参与执行的工作进程的总数，记为工作进程的总数M总。每个进程rank将产生与M总相关的唯一进程秩号N值。
举例说明，进程秩号N值的形式表示采用了与工作进程的总数M总相关，若M总＝5，则说明进程秩号N值为0～4之间的罗马数字，即N值＝[0]、N值＝[1]、N值＝[2]、N值＝[3]或者N值＝[4]；在MPI应用程序执行过程中，N值为唯一的进程标识，将N值＝[0]的进程作为主进程(记为rank主)，并定义其所在的节点为主控节点(记为node主)。除N值＝[0]以外的N值将作为工作进程(记为rank工作)，并定义其所在的节点为工作节点(记为node工作)。
举例说明，进程秩号N值的形式表示采用了与工作进程的总数M总相关，若M总＝15，则说明进程秩号N值为0～14之间的罗马数字，即N值＝[0]、N值＝[1]、N值＝[2]、……、N值＝[13]或者N值＝[14]；在MPI应用程序执行过程中，N值为唯一的进程标识，将N值＝[0]的进程作为主进程(记为rank主)，并定义其所在的节点为主控节点(记为node主)。除N值＝[0]以外的N值将作为工作进程(记为rank工作)，并定义其所在的节点为工作节点(记为node工作)。
步骤101：获取MPI应用程序的本地进程的进程信息，记为本地进程信息
在本发明中，所述中至少包括有进程的进程秩号和工作进程的总数M总。
步骤102：判断是否为0；
若则该本地进程rank本地为主进程rank主，其所在的节点为主控节点node主；
若为除以外的进程秩号，则该本地进程rank本地为工作进程rank工作，其所在的节点为工作节点node工作；
步骤103：若本地进程rank本地为主工作进程rank主，启动SERVER端心跳检测模块6；
在本发明中，服务进程都是以独立进程的方式创建的，采用linux中的execv(译文，execv是linux中的一程进程创建方式)的进程创建方式，而不是直接调用fork(译文，fork是linux中的一程进程创建方式，但与execv不同)，这样的好处在于，直接fork创建的进程仍为MPI进程，受MPI编程规则的约束，服务进程的执行可能会影响到科学计算应用程序的正常执行。本发明的服务进程包括有心跳检测服务进程、可疑事件定位服务进程、以及节点内心跳管理服务进程。所述心跳检测服务进程运行于SERVER端心跳检测模块6，其执行等待接收心跳消息，并进行处理的操作。
步骤104：在MPI的工作进程rank工作执行中，获取可疑事件定位服务对应的锁文件信息，当获取文件锁成功，则启动SERVER端可疑事件定位模块8；若文件锁已被抢占，则说明SERVER端可疑事件定位模块8的服务进程已由该节点上的其它工作进程启动。所述可疑事件定位服务进程运行于SERVER端可疑事件定位模块8，其执行等待接收检测请求，并回复状态响应的操作。
步骤105：在MPI的工作进程rank工作执行中，获取本地心跳管理服务对应的锁文件信息，若获取文件锁成功，则启动节点内心跳管理模块4；若文件锁被抢占，则说明节点内心跳管理模块4的服务进程已由该节点上的其他工作进程启动。所述节点内心跳管理服务进程运行于节点内心跳管理模块4，其执行等待接收重置计时器请求消息，并转入相应处理的操作。
MPI程序运行在多个节点上，每个节点上的可执行文件是相同的，同一个节点上的多个进程可能会执行相同的代码，采用锁文件实现了特定类型的服务进程的单例执行。
节点信息采集模块2
节点信息采集模块2用于收集HPC程序运行时的进程相关信息及各进程运行所在的节点的相关信息，包括MPI进程的进程ID，节点名，IP地址等，为后面的CLIENT端可疑事件定位模块7确定需要检查的节点列表。具体的节点信息采集工作流程为：
步骤201：MPI进程执行时将获取自身进程的进程信息procInfo＝{N值,processId,hostName,ip}，N值为进程秩号，processId为进程号，hostName为进程所在节点的主机名(也是SERVER端心跳检测模块6中涉及的发送节点)，ip为进程所在节点的网络地址；
步骤202：MPI进程执行时根据进程信息procInfo＝{N值,processId,hostName,ip}判断所在节点是否是主控节点node主；
若N值为0时对应的进程为rank主，则所在的节点即为主控节点node主；MPI程序中，对于默认全局通信子，进程之间以不同的进程秩号来相互区分，而N值为0的进程所在的节点通常是执行程序运行命令mpirun或mpiexec的节点。对于所述mpirun和所述mpiexec都是一种MPI实现中的程序执行命令，只是存在于不同的MPI实现中。
步骤203：MPI在工作进程中生成一个进程相关信息的结构体数据；
结构体数据的源代码为：
步骤204：各工作进程rank工作发送本进程的相关信息到主进程rank主；
步骤205：主进程rank主接收来自各个工作进程rank工作发送来的进程相关信息；
在本发明中，节点之间的数据传递采用的是MPI的点对点通信方式。
步骤206：主进程rank主判断是否已经全部接收，若没有全部接收，则继续等待，直到全部接收为止，并获取HPC程序运行所用到的所有节点的信息，简称为节点列表信息NodelistHPC＝{node1,node2,…,noden}。
node1表示MPI进程所在的第一个节点；
node2表示MPI进程所在的第二个节点；
noden表示MPI进程所在的最后一个节点；上述节点之间并不存在顺序。为了方便说明，noden也称为任意一个节点。
主进程rank主将接收到的进程相关信息procInfo＝{N值,processId,hostName,ip}的数量MheartInfo与MPI进程的总数M总进行比较，若相等(MheartInfo＝M总)，则表示主进程rank主已全部接收各个MPI进程的procInfo＝{N值,processId,hostName,ip}，并生成进程信息列表，每个工作进程都会发送进程相关信息，而任意一个节点noden上可能有多个工作进程。若不等(MheartInfo≠M总)，则表示主进程rank主未全部接收各个MPI进程的procInfo＝{N值,processId,hostName,ip}，继续等待，直到全部接收完成。
MPI程序执行过程正常时，硬件系统是正常的，因此只关注程序执行failure(失效)时的硬件系统状态，并不需要周期性地对其进行检测，也就是说，只在程序执行过程出现异常时，检查程序运行所占用的节点硬件系统的状态，从而确定硬件系统故障是否是导致了程序执行过程的failure的决定因素。程序执行过程中出现异常(数值错误除外)会引起进程间消息传递的异常，表现为进程之间消息的发送或者接收失败，反过来异常的消息传递能够很好地体现程序在执行过程中发生了异常。这种异常有可能是软件bug造成的，也可能是硬件系统故障造成的，甚至两者都有。本发明通过监测一段时间内是否进行了消息传递来判断程序执行是否在正常地进展。若一段时间内没有监测到消息传递操作，则怀疑程序执行过程中发生了异常情况，比如进程阻塞，死锁，异常终止等，这些情况下，程序无法正常执行下去，破坏了正常的消息传递。除此之外，程序中的计算代码执行时间过长，超过设定时间，也会表现为在监测期内捕获不到消息传递操作，由此可见，程序执行异常是监测期内未捕获到消息传递这一事件的充分不必要条件，因此，在规定的监测期内，如果没有观测到消息传递操作发生，用户或管理员会怀疑有很大的可能发生了程序异常，而不是对此完全确定，所以需要采用本发明的可疑事件定位模块(7、8)来处理。
本发明的可疑事件定位模块(7、8)需要用到各个工作节点的位置信息，如IP地址。参见图4所示，在程序执行的开始阶段，从HPC程序运行所在的分布式节点采集节点信息，聚集到主控节点，形成节点信息列表，在探测定位阶段，可疑事件定位模块读取该信息列表，轮询地向目标节点发送探测请求，并根据收到的响应消息判断该节点的状态。
本地消息传递监测模块3
参见图5所示，给出了本地消息传递监测模块的工作流程：
步骤301：监测到当前工作进程中有消息传递的操作发生；
在本发明中，实现对本地消息传递的监测存在多种方法，即一种是在二进制级，通过二进制程序插装工具如Pin等，程序执行前进行静态插装或者在程序执行过程中进行动态插装，在消息传递相关函数调用的位置，插装实现特定功能的代码段；另一种是在MPI库级，修改MPI库实现的底层代码，在MPI消息传递的函数调用中添加所需功能的代码，在整个HPC系统中需要重新部署MPI实现；此外，在应用程序级，对消息传递相关的MPI函数调用，添加Wrapper包装器，包装内部MPI函数调用执行前或后添加特定功能的代码段。本发明的具体实现以静态库的方式提供一系列所需特定功能的函数调用，实验采用的应用为Linpack，而Linpack中对MPI消息传递的调用采用了Wrapper的方式，将MPI库提供的MPI函数调用封装在包装器内，可以方便地利用Linpack中提供的Wrapper实现本方案中对程序执行过程中消息传递的监测。
步骤302：查看线程thread的当前标志位flagthread状态；
如果flagthread的状态为“已占用”，则表明本地工作进程上当前已有请求重置计时器的操作，并且正在等待执行或者尚未执行完成，此时不作任何操作，跳转到步骤303；如果flagthread的状态为“空闲”，则表明本地节点上当前并没有正在执行的计时器重置请求，并将flagthread的标志位设置为“已占用”，从而获取使用权限，并转入步骤304。
步骤303：等待下一次消息传递的发生，并跳回到步骤301；
步骤304：创建一个新的工作线程；
步骤305：由新创建的线程发送重置计时器的请求消息；
步骤306：线程thread中任务执行结束后，恢复flagthread的状态至“空闲”。
在本发明中，利用标志位flagthread可以使同一个工作进程rank工作中在一段时间内只会产生一个额外的线程thread，有效地减少了服务端收到的请求数量。工作进程rank工作与线程thread之间并行执行降低了本发明对HPC应用程序性能的影响。
节点内心跳管理模块4
本发明的节点内心跳管理模块4即服务初始化阶段启动的本地心跳管理服务进程，接收本地节点上各个工作进程rank工作发送的计时器重置请求。由于是节点内通信，服务端和客户端之间采用Unix domain UDP的socket(译文，套接字)连接方式进行数据的传输。
参见图6所示，给出了节点内心跳管理模块的工作流程：
步骤401：节点内心跳管理模块4在启动后初始化计时器；
计时器的逾期时间time阈值是人为设定的，不能太大也不能太小，太小会导致频繁超时，将正常的程序执行过程误报为异常，太大会导致异常无法及时发现，诊断时延太高。在本发明的具体实现中，time阈值一般设置为1分钟。
步骤402：本地心跳管理服务进程进入循环等待阶段，等待接收来自本地节点上的工作进程rank工作发送的重置计时器的请求消息request计时器；
步骤403：当本地心跳管理服务进程收到请求消息request计时器时，重置计时器的时间为time阈值；
步骤404：若计时器超时后，进行可疑事件报警，调用CLIENT端心跳检测模块5，向SERVER端心跳检测模块6的发送心跳信息。
在本发明中，通过信号机制实现可疑事件的报警，计时器超时产生SIGALRM信号触发调用信号处理函数。心跳检测模块的CLIENT端以函数调用的方式实现，作为信号处理句柄，负责与心跳检测服务SERVER端建立连接并发送心跳信息。
传统的监控系统中采用心跳机制来获取各个节点的状态是否正常，无论是采用pull的方式，由被监控节点向执行监控的节点发送心跳消息，还是push的方式，由监控节点向被监控节点发送检测请求并获得响应，都需要周期性地进行检测。而在程序调试和程序执行过程中，关注的是在发现程序异常执行时的硬件系统状态，本发明通过本地消息传递监测模块3结合节点内心跳管理模块4实现了在发现消息传递有可疑迹象时，才向外发送心跳消息，当心跳检测服务端接收到心跳信息时，则说明心跳发送方监控的工作进程中在一个监测期内没有发生消息传递操作，导致这种情况的原因有4种：
原因A:MPI程序的代码可划分为两部分，计算代码区和通信代码区，计算代码区用于各种计算任务，通信代码区负责进程之间消息的传递，当工作进程执行计算代码花费的时间过长，那么监测期内很可能不会进行消息传递。
原因B:程序错误导致本地工作进程出现了阻塞、死锁、异常退出等现象，工作进程无法正常进展下去导致不再发生消息传递操作。
原因C：将相互通信的节点称为对等节点，相互通信的进程称为对等进程，某个节点上的工作进程发生异常有可能是由于对等进程的异常引起的，这种现象叫做错误的级联传播。对等节点上的对等进程由于程序错误而出现了阻塞、死锁、异常退出等现象，由于进程之间的相互影响，导致本地工作进程也出现了阻塞、死锁、异常退出等现象，监测期内不会发现消息传递。
原因D：本地工作进程的对等节点发生了硬件系统故障，如硬件的损坏、死机、断电等。这种情况下，该对等节点上的工作进程异常结束，导致本地工作进程执行过程中发生阻塞、死锁或异常退出等问题，不再发生消息传递操作。
上述四种原因都会导致监测期内捕获不到消息传递，计时器超时，触发心跳信息的产生和发送。而原因A属于程序的正常执行，原因B、C和D属于程序的异常执行。
本发明中的心跳检测模块由CLIENT端和SERVER端两部分组成，CLIENT端位于运行HPC应用程序工作进程的各个节点node工作上，以静态库方法函数调用的方式实现，在发现可疑事件的时候被调用，负责产生并发送心跳信息；SERVER端位于主控节点node主上，即服务初始化阶段启动的心跳检测服务，负责接收各个节点传来的心跳信息，并做进一步处理。
在本发明中，心跳信息记为heartInfo＝{processId,hostName,ip}，其中的各元素则是进程信息procInfo＝{N值,processId,hostName,ip}中的关联信息。
CLIENT端心跳检测模块5
在本发明中CLIENT端心跳检测模块5以静态库函数调用的形式实现，当节点内心跳管理模块4发现所在节点消息传递行为异常时，调用该函数调用，CLIENT端心跳检测模块5会与SERVER端心跳检测模块6建立起TCP socket连接，向SERVER端心跳检测模块6发送心跳信息。
SERVER端心跳检测模块6
参见图7所示，给出了SERVER端心跳检测模块的工作流程：
步骤601：MPI工作进程rank工作在服务初始化阶段启动心跳检测服务进程；
心跳检测服务进程启动后进入循环等待阶段，等待接收来自其他工作节点node工作的心跳信息，在程序正常执行过程中，频繁地消息传递操作会及时地重置计时器，SERVER端心跳检测模块6接收不到任何心跳信息，或者程序执行的某个时间段内计算代码花费大量时间，对应的监测期内没有发生消息传递，如果监测期的逾期时间time阈值设置的合理，上述情况并不是频发的，接下来的一个或几个监测期内，程序执行过程中又出现频繁地消息传递，此时不再产生并发送心跳消息，SERVER端心跳检测模块6只接收到若干数量的心跳消息，对于原因B、C和D程序执行异常情况下，计时器不断的计时并超时，SERVER端心跳检测模块6会不断收到心跳消息，本发明中设置了一个心跳数量的阈值M心跳阈值作为区别原因A和B、C和D的临界条件。
步骤602：SERVER端心跳检测模块6接收心跳信息heartInfo＝{processId,hostName,ip}，并记录保存；
心跳信息的产生和发送并不是频发的，为了保持信息传递的可靠性，心跳检测的CLIENT端与SERVER端采用TCP socket的方式建立连接。
步骤603：检查已收到的心跳信息的数量M心跳是否超过设定的阈值M心跳阈值；
当心跳检测SERVER端接收到的心跳消息的数量超过阈值时，即M心跳＞M心跳阈值，则可确定此时的可疑事件是由原因B、C或D引起的程序执行过程异常；若M心跳≤M心跳阈值，SERVER端心跳检测模块6继续等待下一条心跳信息的到来；
步骤604：SERVER端心跳检测模块6按照消息接收的先后顺序，形成心跳消息列表
heartInfo1表示SERVER端心跳检测模块6接收到的第一条心跳信息；
heartInfo2表示SERVER端心跳检测模块6接收到的第二条心跳信息；
表示SERVER端心跳检测模块6接收到的最后一条心跳信息；
步骤605：当M心跳＞M心跳阈值成立时，通过SERVER端心跳检测模块6触发CLIENT端可疑事件定位模块7；
在本发明中，本地消息传递监测模块3和节点内心跳管理模块4结合所形成的只在程序执行过程中出现可疑行为时才发送报警信息的方式形成了精简心跳机制。本发明通过基于消息传递的精简心跳机制成功地实现了程序执行异常时的可疑事件自动报警功能，本质上是基于程序行为规则的异常检测，当感知到程序执行过程发生了异常时，需要判断导致这种异常的错误是由程序错误引起的还是由系统的硬件故障引起的，需要对当前的硬件系统状态进行检测，可疑事件定位模块也分为CLIENT端和SERVER端两部分，两者之间采用UDP socket的方式建立连接，CLIENT端以函数调用的形式实现，在需要进行状态检测时被调用，SERVER端即服务初始化阶段在各个工作节点上启动的可疑事件检测定位服务，负责接收检测请求并作出应答。
可疑事件定位模块也分为SERVER端和CLIENT端两部分，之间采用UDP的方式建立socket连接进行消息的发送和接收。SERVER端位于每个工作节点node工作上，即由服务初始化模块在程序开始阶段启动的可疑事件探测定位服务，等待接收来自CLIENT端的探测请求并回复响应信息。CLIENT端位于主控节点node主上，以函数调用的方式实现，当触发可疑事件探测定位时，采用轮询地方式，向每个工作节点发送探测请求，获取各个节点的硬件系统状态。
CLIENT端可疑事件定位模块7
在本发明中CLIENT端可疑事件定位模块7以静态库函数的形式实现，当SERVER端心跳检测模块6，收到的心跳消息数量超过心跳阈值，即M心跳＞M心跳阈值时，调用CLIENT端可疑事件定位模块7对应的库函数调用，与SERVER端可疑事件定位模块8建立UDP socket的方式建立连接，并由node主向node工作发送状态检测请求request节点。
CLIENT端的可疑事件定位模块7的工作流程如下：
步骤701：SERVER端心跳检测模块6在发现有可疑事件发生后，即接收到的心跳信息的数量超过阈值，即M心跳＞M心跳阈值，进入检测定位阶段；
步骤702：CLIENT端可疑事件定位模块7读取需要检测的节点列表信息NodelistHPC＝{node1,node2,…,noden}；
在本发明中，所述NodelistHPC＝{node1,node2,…,noden}来源于程序开始阶段的节点信息采集，节点列表信息中的每个元素对应一个节点的IP地址。
步骤703：检测阶段，待测节点集的初始状态与所述NodelistHPC＝{node1,node2,…,noden}是相同的；先判断是否为空，若为空，则表示轮询检测结束，若不为空，从待测节点集取一个节点作为目标节点node目标，并将目标节点node目标从中剔除；再向该目标节点node目标以UDPsocket的方式发送状态检测请求request节点到SERVER端可疑事件定位模块8；
步骤704：CLIENT端可疑事件定位模块7等待接收SERVER端可疑事件定位模块8的状态应答消息answer节点；
从收到的状态应答消息answer节点中可以判断目标节点node目标当前硬件系统的状态，本发明采用多次重复检测的方法，如果多次检测后，获取状态应答消息answer节点仍失败或者超时，则认为目标节点node目标硬件系统故障；
步骤705：将目标节点node目标的硬件系统运行状态检测结果保存为结果文件中；所述结果文件可以是txt格式、doc格式、xml格式等。
检测结果以值对<nodeName，nodeIP，alive/dead>的形式存储。
nodeName代表对应节点的主机名。
nodeIP代表对应节点的网络地址。
alive代表对应节点的硬件状态为正常。
dead代表相应的节点的状态为硬件故障。
步骤706：CLIENT端可疑事件定位模块7轮询至下一个目标节点进行检测，跳转至步骤703。
SERVER端可疑事件定位模块8
参见图8所示，对于可疑事件检测定位模块的SERVER端，工作流程如下：
步骤801：服务初始化阶段MPI工作进程rank工作在各个工作节点node工作上启动SERVER端可疑事件定位模块8，并进入循环等待，准备接收来自CLIENT端可疑事件定位模块7的状态检测请求request节点；
步骤802：SERVER端可疑事件定位模块8接收到状态检测请求request节点后，检测本地硬件系统的运行状态，形成对检测请求的应答信息answer节点；
步骤803：SERVER端可疑事件定位模块8将状态应答信息answer节点发送到CLIENT端的可疑事件定位模块7；
步骤804：SERVER端可疑事件定位模块8退出本次状态检测，跳至步骤801，循环等待接收下一次的状态检测请求。
报告生成模块9
本发明根据可疑事件检测定位的结果以及收到的心跳信息进行综合分析，给出HPC程序运行失败的软硬件原因判别，参见图9所示，给出了报告生成模块9的工作流程：
步骤901：报告生成模块9读取CLIENT端可疑事件定位模块7生成的结果文件(即步骤705)；
步骤902：报告生成模块9查看每个节点对应的状态是否为故障，即值对<nodeName，nodeIP，alive/dead>中的dead为故障；
步骤903：若存在故障节点node故障，则判定HPC程序运行失败是由硬件系统故障引起的，并将所有的故障节点信息保存在报告文件中，所述报告文件可以呈现给用户或管理员；
步骤904：管理员通过获得故障节点node故障的位置信息(即nodeName，nodeIP)，对故障节点node故障的硬件系统进行检查和修复。
步骤905：若不存在故障节点node故障，则说明HPC程序执行失败是由软件错误引起的，将收到的心跳消息列表所对应的异常进程rank异常的进程相关信息保存在报告文件中，所述报告文件可以呈现给用户或管理员。
根据错误级联传播效应，越早发生错误的位置会越早地产生心跳信息，因此心跳检测服务端越早接收到的心跳信息来源可能越靠近错误的根源，通过心跳信息可以锁定执行过程异常的工作进程的位置，结合程序执行过程中调用MPI通信函数的参数信息，进程异常退出时形成的coredump文件以及串行程序调试中广泛采用的程序切片静态分析等方法进行错误根源定位。
服务关闭模块10
本发明中为了减小对HPC应用程序性能的影响，在服务初始化阶段启动的三个服务即心跳检测服务、可疑事件检测定位服务以及节点内心跳管理服务都是以独立进程的方式启动的，在HPC程序执行结束后，服务进程并不随之退出，鉴于服务进程运行在分布式的工作节点node工作上，需要进行远程通信才能将其关闭，本发明方法利用各个工作节点node工作上的SERVER端可疑事件定位模块8作为服务关闭命令的接收者和执行者，参见图10所示，给出了服务关闭模块10的工作流程：
步骤一：服务关闭模块10读取节点信息文件NodelistHPC＝{node1,node2,…,noden}，获取各个工作节点的地址；
步骤二：清理阶段，待清理节点集的初始状态与所述NodelistHPC＝{node1,node2,…,noden}是相同的；先判断是否为空，若为空，则服务关闭模块10退出清理工作；若不为空，服务关闭模块10从中取出任意一个节点作为待清理节点node待清理，并将node待清理从中剔除；再向该node待清理发送关闭服务请求消息request清理；
在本发明中，借助各个工作节点上的可疑事件检测服务模块的SERVER端作为服务关闭指令的接收端，设置一个类别属性区分状态检测请求消息和服务关闭请求。
步骤三：待清理节点node待清理接收到关闭服务请求消息request清理后，执行相应的关闭服务操作。
在本发明中，如果node待清理是工作节点node工作，程序执行期间运行有两个服务进程，分别是节点内心跳管理模块4和SERVER端可疑事件定位模块8，先关闭节点内心跳管理模块4，然后关闭SERVER端可疑事件定位模块8，而如果node待清理是主控节点node主，程序执行期间运行三个服务进程，分别是节点内心跳管理模块4、SERVER端心跳检测模块6和SERVER端可疑事件定位模块8，并将节点内心跳管理模块4、SERVER端心跳检测模块6和SERVER端可疑事件定位模块8依次关闭。
实施例1
高性能计算应用程序大多采用消息传递的方式进行进程间通信，此类程序运行规模大，运行时间长，在程序执行期间普遍存在着消息传递，本发明通过精简心跳机制监测消息传递行为的异常，一旦触发了设置的可疑事件阈值，便对HPC中的节点进行轮询检测，一方面能够较为及时地发现程序执行过程中出现的异常情况，另一方面解决了程序执行异常或失败是由软件引起的还是硬件引起的，这一困扰开发、调试、管理人员的问题。避免了用户耗费过多精力确定问题来源，更有针对性地进行系统维护和软件调试。
参见图11所示的Linpack性能开销对比图，单个节点上在不同的问题规模下，添加本发明方法前后并未出现明显的性能开销的增大，个别情况下，本发明方法添加后的程序运行花费的时间反而比未添加本发明方法时程序运行花费的时间稍低，原因在于：本发明方法所产生的开销，主要源自针对消息传递而采取的监控和管理操作，这些在编译过程中以插桩的方式实现，性能开销的根源来自这些插桩代码的执行，而这些操作花费的时间极少，在毫秒级到微妙级，而Linpack程序中执行一次迭代计算的时间在秒到毫秒级之间，两者相互比较，至少存在两个数量级的差距，因此本发明方法所造成的性能开销可以忽略不计。
而在多个节点上也表现出相似的现象，参见图12所示的多节点上本发明方法实施前后对Linpack性能的影响，在多节点上对于同一问题规模等于1000时，Linpack程序运行时间随进程数的增多而显著降低并在一定进程数后达到一个稳定状态，而本发明方法的添加并未对程序运行的开销造成显著的影响，甚至说可以忽略不计。问题规模是一个表示矩阵大小的参数，无单位。
参见图13所示的Linpack运行时间随规模变化图，在不同的问题规模下各自运行Linpack原始程序10次，取得最大值、最小值和平均值，可以看出Linpack每次运行所花费的时间都不同，但对于同一问题规模，Linpack的运行时间是会上下一定范围内浮动的，这也解释了为什么个别情况下，即使添加了本发明方法，运行Linpack花费的时间反而比未添加本发明方法时要稍低。
本发明公开了一种基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，该系统克服了集中式检测机制性能开销大，扩展性差的问题，通过对消息传递行为的异常监测，精简心跳机制为每个节点上的工作进程设置消息监控计时器，当消息行为发生异常时，才会向主控节点发送心跳消息，而在正常情况下,并不用发送心跳，从而避免了对网络资源的占用，扩展性也不会因此受限，利用可疑事件定位机制，只在需要的时候进行状态检查，添加本发明方法对应用程序的执行所造成的性能开销可以忽略不计，易于扩展支持高性能计算机上的大规模并行应用程序。

Claims (10)

1.一种基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于：检测系统由服务初始化模块(1)、节点信息采集模块(2)、本地消息传递监测模块(3)、节点内心跳管理模块(4)、CLIENT端心跳检测模块(5)、SERVER端心跳检测模块(6)、CLIENT端可疑事件检测定位模块(7)、SERVER端可疑事件检测定位模块(8)、报告生成模块(9)和服务关闭模块(10)组成；
服务初始化模块(1)用来初始化启动三个服务进程，即心跳检测服务、可疑事件检测定位服务和本地心跳管理服务；
节点信息采集模块(2)收集HPC程序运行时的进程相关信息及各进程运行所在的节点相关信息；
本地消息传递监测模块(3)监测本地工作进程中的消息传递操作，当存在消息传递发生时，生成一个请求重置计时器的通知，通过计时器超时警报该进程中消息传递的异常行为；
节点内心跳管理模块(4)对同一个节点上运行的隶属于同一个HPC程序的多个工作进程的状态进行监测和管理，接收工作进程发送来重置计时器请求，重置计时器，当计时器超时时，向主控节点的SERVER端心跳检测模块(6)发送一条心跳消息；通过本地消息传递监测模块(3)结合节点内心跳管理模块(4)实现了在发现消息传递有可疑迹象时，才向外发送心跳消息，当心跳检测服务端接收到心跳信息时，则说明心跳发送方监控的工作进程中在一个监测期内没有发生消息传递操作，导致这种情况的原因有4种：
原因A:MPI程序的代码可划分为两部分，计算代码区和通信代码区，计算代码区用于各种计算任务，通信代码区负责进程之间消息的传递，当工作进程执行计算代码花费的时间过长，那么监测期内很可能不会进行消息传递；
原因B:程序错误导致本地工作进程出现了阻塞、死锁、异常退出的现象，工作进程无法正常进展下去导致不再发生消息传递操作；
原因C：将相互通信的节点称为对等节点，相互通信的进程称为对等进程，某个节点上的工作进程发生异常有可能是由于对等进程的异常引起的，这种现象叫做错误的级联传播；对等节点上的对等进程由于程序错误而出现了阻塞、死锁、异常退出的现象，由于进程之间的相互影响，导致本地工作进程也出现了阻塞、死锁、异常退出的现象，监测期内不会发现消息传递；
原因D：本地工作进程的对等节点发生了硬件系统故障，这种情况下，该对等节点上的工作进程异常结束，导致本地工作进程执行过程中发生阻塞、死锁或异常退出等问题，不再发生消息传递操作；
心跳检测模块包括SERVER端和CLIENT端两部分，之间采用TCP的方式建立连接进行消息的发送和接收；SERVER端位于主控节点上，等待接收来自各个工作节点的心跳消息，设定一个程序行为异常报警的心跳阈值，CLIENT端以函数调用的方式被实现，由各个工作节点上的本地心跳管理服务调用，向SERVER端发送心跳消息；SERVER端接收到的心跳消息数量超过心跳阈值时，判定当前程序执行过程中存在可疑事件发生导致程序行为异常，从而触发可疑事件探测定位；所述CLIENT端心跳检测模块(5)以静态库函数调用的形式实现，当节点内心跳管理模块(4)发现所在节点消息传递行为异常时，调用该函数调用，CLIENT端心跳检测模块(5)会与SERVER端心跳检测模块(6)建立起TCP socket连接，向SERVER端心跳检测模块(6)发送心跳信息；
可疑事件探测定位模块也分为SERVER端和CLIENT端两部分，之间采用UDP的方式建立连接进行消息的发送和接收；SERVER端位于每个工作节点上，即由服务初始化模块在程序开始阶段启动的可疑事件探测定位服务，等待接收来自CLIENT端的探测请求并回复响应信息；CLIENT端位于主控节点上，以函数调用的方式实现，当触发可疑事件探测定位时，采用轮询地方式，向每个工作节点发送探测请求，获取各个节点的硬件系统状态；
报告生成模块(9)记录可疑事件探测定位的结果，内容包括节点名、节点IP以及节点状态，即正常或者故障；当存在节点状态为故障时，判定导致HPC程序执行失效的原因为硬件系统故障，否则为软件错误引起的；
服务关闭模块(10)将在程序执行结束后对服务初始化模块所启动的三个服务即心跳检测服务、可疑事件探测定位服务和本地心跳管理服务进行清理；原因是在初始化阶段，为了避免对HPC程序执行的影响，将这三个服务以独立进程的方式而非MPI进程的方式运行。
2.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于在服务初始化模块(1)中的处理流程为：
步骤101：获取MPI应用程序的本地进程的进程信息，记为本地进程信息 表示进程秩号，M总表示工作进程的总数；
步骤102：判断是否为0；
若则该本地进程rank本地为主工作进程rank主，其所在的节点为主控节点node主；
若为除以外的进程秩号，则该本地进程rank本地为工作进程rank工作，其所在的节点为工作节点node工作；
步骤103：若本地进程rank本地为主工作进程rank主，启动SERVER端心跳检测模块(6)；
步骤104：在MPI的工作进程rank工作执行中，获取可疑事件检测定位服务对应的锁文件信息，当获取文件锁成功，则启动SERVER端可疑事件定位模块(8)；若文件锁已被抢占，则说明SERVER端可疑事件定位模块(8)的服务进程已由该节点上的其它工作进程启动；所述可疑事件定位服务进程运行于SERVER端可疑事件定位模块(8)，其执行等待接收检测请求，并回复状态响应的操作；
步骤105：在MPI的工作进程rank工作执行中，获取本地心跳管理服务对应的锁文件信息，若获取文件锁成功，则启动节点内心跳管理模块(4)；若文件锁被抢占，则说明节点内心跳管理模块(4)的服务进程已由该节点上的其他工作进程启动；所述节点内心跳管理服务进程运行于节点内心跳管理模块(4)，其执行等待接收重置计时器请求消息，并转入相应处理的操作。
3.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于所述节点信息采集工作流程为：
步骤201：MPI进程执行时将获取自身进程的进程信息procInfo＝{N值,processId,hostName,ip}，N值为进程秩号，processId为进程号，hostName为进程所在节点的主机名，ip为进程所在节点的网络地址；
步骤202：MPI进程执行时根据进程信息procInfo＝{N值,processId,hostName,ip}判断所在节点是否是主控节点node主；
若N值为0时对应的进程为rank主，则所在的节点即为主控节点node主；MPI程序中，对于默认全局通信子，进程之间以不同的进程秩号来相互区分，而N值为0的进程所在的节点通常是执行程序运行命令mpirun或mpiexec的节点；
步骤203：MPI在工作进程中生成一个进程相关信息的结构体数据；
步骤204：各工作进程rank工作发送本进程的相关信息到主进程rank主；
步骤205：主进程rank主接收来自各个工作进程rank工作发送来的进程相关信息；
步骤206：主进程rank主判断是否已经全部接收，若没有全部接收，则继续等待，直到全部接收为止，并获取HPC程序运行所用到的所有节点的信息，简称为节点列表信息NodelistHPC＝{node1,node2,…,noden}，node1表示MPI进程所在的第一个节点，node2表示MPI进程所在的第二个节点，noden表示MPI进程所在的最后一个节点。
4.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于本地消息传递监测模块的工作流程：
步骤301：监测到当前工作进程中有消息传递的操作发生；
步骤302：查看线程thread的当前标志位flagthread状态；
如果flagthread的状态为“已占用”，则表明本地工作进程上当前已有请求重置计时器的操作，并且正在等待执行或者尚未执行完成，此时不作任何操作，跳转到步骤303；如果flagthread的状态为“空闲”，则表明本地节点上当前并没有正在执行的计时器重置请求，并将flagthread的标志位设置为“已占用”，从而获取使用权限，并转入步骤304；
步骤303：等待下一次消息传递的发生，并跳回到步骤301；
步骤304：创建一个新的工作线程；
步骤305：由新创建的线程发送重置计时器的请求消息；
步骤306：线程thread中任务执行结束后，恢复flagthread的状态至“空闲”。
5.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于节点内心跳管理模块的工作流程：
步骤401：初始化计时器；
计时器的逾期时间time阈值，设置为1分钟；
步骤402：本地心跳管理服务进程进入循环等待阶段，等待接收来自本地节点上的工作进程rank工作发送的重置计时器的请求消息request计时器；
步骤403：当本地心跳管理服务进程收到请求消息request计时器时，重置计时器的时间为time阈值；
步骤404：若计时器超时后，进行可疑事件报警，调用CLIENT端心跳检测模块(5)，向SERVER端心跳检测模块(6)的发送心跳信息。
6.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于：SERVER端心跳检测模块的工作流程：
步骤601：MPI工作进程rank工作在服务初始化阶段启动心跳检测服务进程；
步骤602：SERVER端心跳检测模块(6)接收心跳信息heartInfo＝{processId,hostName,ip}，并记录保存；
步骤603：检查已收到的心跳信息的数量M心跳是否超过设定的阈值M心跳阈值；
当心跳检测SERVER端接收到的心跳消息的数量超过阈值时，即M心跳＞M心跳阈值，则可确定此时的可疑事件是由原因B、C或D引起的程序执行过程异常；若M心跳≤M心跳阈值，SERVER端心跳检测模块(6)继续等待下一条心跳信息的到来；
步骤604：SERVER端心跳检测模块(6)按照消息接收的先后顺序，形成心跳消息列表
heartInfo1表示SERVER端心跳检测模块(6)接收到的第一条心跳信息；
heartInfo2表示SERVER端心跳检测模块(6)接收到的第二条心跳信息；
表示SERVER端心跳检测模块(6)接收到的最后一条心跳信息；
步骤605：当M心跳＞M心跳阈值成立时，通过SERVER端心跳检测模块(6)触发CLIENT端可疑事件定位模块(7)。
7.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于CLIENT端的可疑事件定位模块7的工作流程如下：
步骤701：SERVER端心跳检测模块(6)在发现有可疑事件发生后，即接收到的心跳信息的数量超过阈值，即M心跳＞M心跳阈值，进入检测定位阶段；
步骤702：CLIENT端可疑事件定位模块(7)读取需要检测的节点列表信息NodelistHPC＝{node1,node2,…,noden}；
步骤703：检测阶段，待测节点集的初始状态与所述NodelistHPC＝{node1,node2,…,noden}是相同的；先判断是否为空，若为空，则表示轮询检测结束，若不为空，从待测节点集取一个节点作为目标节点node目标，并将目标节点node目标从中剔除；再向该目标节点node目标以UDPsocket的方式发送状态检测请求request节点到SERVER端可疑事件定位模块(8)；
步骤704：CLIENT端可疑事件定位模块(7)等待接收SERVER端可疑事件定位模块(8)的状态应答消息answer节点；
步骤705：将目标节点node目标的硬件系统运行状态检测结果保存为结果文件中；
检测结果以值对<nodeName，nodeIP，alive/dead>的形式存储；
nodeName代表对应节点的主机名；
nodeIP代表对应节点的网络地址；
alive代表对应节点的硬件状态为正常；
dead代表相应的节点的状态为硬件故障；
步骤706：CLIENT端可疑事件定位模块(7)轮询至下一个目标节点进行检测，跳转至步骤703。
8.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于：对于可疑事件检测定位模块的SERVER端，工作流程如下：
步骤801：服务初始化阶段MPI工作进程rank工作在各个工作节点node工作上启动SERVER端可疑事件定位模块(8)，并进入循环等待，准备接收来自CLIENT端可疑事件定位模块7的状态检测请求request节点；
步骤802：SERVER端可疑事件定位模块(8)接收到状态检测请求request节点后，检测本地硬件系统的运行状态，形成对检测请求的应答信息answer节点；
步骤803：SERVER端可疑事件定位模块(8)将状态应答信息answer节点发送到CLIENT端的可疑事件定位模块(7)；
步骤804：SERVER端可疑事件定位模块(8)退出本次状态检测，跳至步骤801，循环等待接收下一次的状态检测请求。
9.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于报告生成模块(9)的工作流程：
步骤901：报告生成模块(9)读取CLIENT端可疑事件定位模块(7)生成的结果文件；
步骤902：报告生成模块(9)查看每个节点对应的状态是否为故障，即值对<nodeName，nodeIP，alive/dead>中的dead为故障；
步骤903：若存在故障节点node故障，则判定HPC程序运行失败是由硬件系统故障引起的，并将所有的故障节点信息保存在报告文件中，所述报告文件可以呈现给用户或管理员；
步骤904：管理员通过获得故障节点node故障的位置信息，即nodeName，nodeIP，对故障节点node故障的硬件系统进行检查和修复；
步骤905：若不存在故障节点node故障，则说明HPC程序执行失败是由软件错误引起的，将收到的心跳消息列表所对应的异常进程rank异常的进程相关信息保存在报告文件中，所述报告文件可以呈现给用户或管理员。
10.根据权利要求1所述的基于消息传递的HPC大规模并行程序异常自动监测及软硬件原因判断的检测系统，其特征在于服务关闭模块(10)的处理流程为：
步骤一：服务关闭模块(10)读取节点信息文件NodelistHPC＝{node1,node2,…,noden}，获取各个工作节点的地址；
步骤二：清理阶段，待清理节点集的初始状态与所述是相同的；先判断是否为空，若为空，则服务关闭模块(10)退出清理工作；若不为空，服务关闭模块(10)从中取出任意一个节点作为待清理节点node待清理，并将node待清理从中剔除；再向该node待清理发送关闭服务请求消息request清理；
步骤三：待清理节点node待清理接收到关闭服务请求消息request清理后，执行相应的关闭服务操作。
CN201610854431.3A 2016-09-27 2016-09-27 基于消息传递的hpc大规模并行程序异常的检测系统 Expired - Fee Related CN106445781B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610854431.3A CN106445781B (zh) 2016-09-27 2016-09-27 基于消息传递的hpc大规模并行程序异常的检测系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610854431.3A CN106445781B (zh) 2016-09-27 2016-09-27 基于消息传递的hpc大规模并行程序异常的检测系统

Publications (2)

Publication Number Publication Date
CN106445781A true CN106445781A (zh) 2017-02-22
CN106445781B CN106445781B (zh) 2019-03-26

Family

ID=58170479

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610854431.3A Expired - Fee Related CN106445781B (zh) 2016-09-27 2016-09-27 基于消息传递的hpc大规模并行程序异常的检测系统

Country Status (1)

Country Link
CN (1) CN106445781B (zh)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107153595A (zh) * 2016-03-04 2017-09-12 福建天晴数码有限公司 分布式数据库系统的故障检测方法及其系统
CN107480005A (zh) * 2017-07-31 2017-12-15 惠州华阳通用电子有限公司 一种Linux系统进程守护方法
CN107957915A (zh) * 2017-11-21 2018-04-24 上海壹账通金融科技有限公司 一种被调用方系统的心跳检测方法、存储介质和服务器
CN109002368A (zh) * 2017-06-07 2018-12-14 奥特润株式会社 监控设备的工作方法及多核系统
CN109412891A (zh) * 2018-10-19 2019-03-01 郑州云海信息技术有限公司 一种检测客户端状态的方法和装置
CN109646046A (zh) * 2018-12-29 2019-04-19 深圳开立生物医疗科技股份有限公司 应用于超声医疗设备的智能分析方法及相关设备
CN109697193A (zh) * 2017-10-24 2019-04-30 中兴通讯股份有限公司 一种确定异常节点的方法、节点及计算机可读存储介质
CN109933492A (zh) * 2019-03-22 2019-06-25 北京极简智能科技有限公司 一种软件异常溯源方法、系统、设备及存储介质
CN110384479A (zh) * 2018-04-17 2019-10-29 三星电子株式会社 基于运动传感器和光学传感器的心律失常分类系统装置
CN111179468A (zh) * 2019-12-31 2020-05-19 深圳一清创新科技有限公司 无人车故障检测方法、装置、计算机设备和存储介质
CN111209007A (zh) * 2020-01-17 2020-05-29 济南浪潮高新科技投资发展有限公司 一种基于移动环境监控可控设备软件实现方法
CN111274086A (zh) * 2020-01-15 2020-06-12 湖北工程学院 一种计算机软件故障监测系统
CN115243318A (zh) * 2022-07-01 2022-10-25 华迪计算机集团有限公司 一种物联网数据透传方法及系统
CN117056926A (zh) * 2023-10-09 2023-11-14 深圳安天网络安全技术有限公司 一种文件检测系统、电子设备及存储介质
CN117395263A (zh) * 2023-12-12 2024-01-12 苏州元脑智能科技有限公司 一种数据同步方法、装置、设备和存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080010681A1 (en) * 2003-01-07 2008-01-10 Francois-Dominique Armingaud System and method for real-time detection of computer system files intrusion
CN103902425A (zh) * 2012-12-28 2014-07-02 研祥智能科技股份有限公司 计算机系统的状态监测方法及装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080010681A1 (en) * 2003-01-07 2008-01-10 Francois-Dominique Armingaud System and method for real-time detection of computer system files intrusion
CN103902425A (zh) * 2012-12-28 2014-07-02 研祥智能科技股份有限公司 计算机系统的状态监测方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
刘轶等: "SimHPC:一种基于执行驱动的大规模并行系统模拟器", 《计算机学报》 *

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107153595A (zh) * 2016-03-04 2017-09-12 福建天晴数码有限公司 分布式数据库系统的故障检测方法及其系统
CN107153595B (zh) * 2016-03-04 2020-03-17 福建天晴数码有限公司 分布式数据库系统的故障检测方法及其系统
CN109002368A (zh) * 2017-06-07 2018-12-14 奥特润株式会社 监控设备的工作方法及多核系统
CN107480005A (zh) * 2017-07-31 2017-12-15 惠州华阳通用电子有限公司 一种Linux系统进程守护方法
CN109697193A (zh) * 2017-10-24 2019-04-30 中兴通讯股份有限公司 一种确定异常节点的方法、节点及计算机可读存储介质
CN107957915A (zh) * 2017-11-21 2018-04-24 上海壹账通金融科技有限公司 一种被调用方系统的心跳检测方法、存储介质和服务器
CN110384479A (zh) * 2018-04-17 2019-10-29 三星电子株式会社 基于运动传感器和光学传感器的心律失常分类系统装置
CN109412891B (zh) * 2018-10-19 2022-04-22 郑州云海信息技术有限公司 一种检测客户端状态的方法和装置
CN109412891A (zh) * 2018-10-19 2019-03-01 郑州云海信息技术有限公司 一种检测客户端状态的方法和装置
CN109646046A (zh) * 2018-12-29 2019-04-19 深圳开立生物医疗科技股份有限公司 应用于超声医疗设备的智能分析方法及相关设备
CN109933492B (zh) * 2019-03-22 2023-01-24 北京极简智能科技有限公司 一种软件异常溯源方法、系统、设备及存储介质
CN109933492A (zh) * 2019-03-22 2019-06-25 北京极简智能科技有限公司 一种软件异常溯源方法、系统、设备及存储介质
CN111179468A (zh) * 2019-12-31 2020-05-19 深圳一清创新科技有限公司 无人车故障检测方法、装置、计算机设备和存储介质
CN111274086A (zh) * 2020-01-15 2020-06-12 湖北工程学院 一种计算机软件故障监测系统
CN111274086B (zh) * 2020-01-15 2023-06-13 湖北工程学院 一种计算机软件故障监测系统
CN111209007A (zh) * 2020-01-17 2020-05-29 济南浪潮高新科技投资发展有限公司 一种基于移动环境监控可控设备软件实现方法
CN111209007B (zh) * 2020-01-17 2023-03-31 山东浪潮科学研究院有限公司 一种基于移动环境监控可控设备软件实现方法
CN115243318A (zh) * 2022-07-01 2022-10-25 华迪计算机集团有限公司 一种物联网数据透传方法及系统
CN117056926A (zh) * 2023-10-09 2023-11-14 深圳安天网络安全技术有限公司 一种文件检测系统、电子设备及存储介质
CN117056926B (zh) * 2023-10-09 2024-01-26 深圳安天网络安全技术有限公司 一种文件检测系统、电子设备及存储介质
CN117395263A (zh) * 2023-12-12 2024-01-12 苏州元脑智能科技有限公司 一种数据同步方法、装置、设备和存储介质
CN117395263B (zh) * 2023-12-12 2024-03-12 苏州元脑智能科技有限公司 一种数据同步方法、装置、设备和存储介质

Also Published As

Publication number Publication date
CN106445781B (zh) 2019-03-26

Similar Documents

Publication Publication Date Title
CN106445781A (zh) 基于消息传递的hpc大规模并行程序异常自动监测及软硬件原因判断的检测系统
CN106789306B (zh) 通信设备软件故障检测收集恢复方法和系统
US9298525B2 (en) Adaptive fault diagnosis
Lou et al. Software analytics for incident management of online services: An experience report
Gu et al. Online anomaly prediction for robust cluster systems
CN110430071A (zh) 业务节点故障自愈方法、装置、计算机设备及存储介质
JP2005216066A (ja) 異常検出システム及びその方法
US20160378583A1 (en) Management computer and method for evaluating performance threshold value
US10831579B2 (en) Error detecting device and error detecting method for detecting failure of hierarchical system, computer readable recording medium, and computer program product
US11334468B2 (en) Checking a correct operation of an application in a cloud environment
CN109240851A (zh) 一种自主式实现批量bmc自恢复的方法及系统
CN115118621B (zh) 一种基于依赖关系图的微服务性能诊断方法及系统
Demirbaga et al. Autodiagn: An automated real-time diagnosis framework for big data systems
CN110798339A (zh) 一种基于分布式任务调度框架的任务容灾方法
CN116684256B (zh) 节点故障监测方法、装置、系统、电子设备及存储介质
Guan et al. Anomaly detection in large-scale coalition clusters for dependability assurance
CN103731315A (zh) 一种服务器故障检测方法
Wang et al. A methodology for root-cause analysis in component based systems
TWI292091B (en) Computer performance evaluator and application method thereof
CN116468423A (zh) 一种运维应急协同方法、系统和终端设备
CN112100019A (zh) 面向大规模系统的多源故障协同分析定位方法
JP4575020B2 (ja) 障害解析装置
Narayanan et al. Towards' integrated'monitoring and management of datacenters using complex event processing techniques
CN109274533A (zh) 一种基于规则引擎的Web服务故障的定位装置和方法
Mishra et al. Model based approach for autonomic availability management

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210420

Address after: 100160, No. 4, building 12, No. 128, South Fourth Ring Road, Fengtai District, Beijing, China (1515-1516)

Patentee after: Kaixi (Beijing) Information Technology Co.,Ltd.

Address before: 100191 Haidian District, Xueyuan Road, No. 37,

Patentee before: BEIHANG University

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20190326

Termination date: 20210927