CN106294059A - 网管系统中进程的恢复方法及装置 - Google Patents

Abstract

本发明提供了一种网管系统中进程的恢复方法及装置，该网管系统中进程的恢复方法包括：按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；判断网管系统进程的系统资源申请量是否符合预设条件；以及在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。通过本发明，解决了相关技术中系统资源申请没有得到释放造成的网管系统故障的问题，进而达到了降低网管系统故障发生率，提高网管系统可用性的技术效果。

Description

网管系统中进程的恢复方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种网管系统中进程的恢复方法及装置。

背景技术

随着网管系统越来越庞大，功能越来越多，管理的设备种类和数量也越来越多，进而出现了需要多个进程协作管理的需求，比如一个网络管理器(Manager)进程协同多个子网管理器(Subnet Manager)进程工作，每个子网管理器管理若干的网元，网络管理器负责把消息转发到子网管理器以及收集来自每个子网管理器的消息汇总上报。工程中经常出现一些故障，比如某个子网管理器出现故障进程退出了，或者进程资源耗尽不能正常工作了，需要有一个管理机制来重启发生故障的进程来确保整个网管系统的正常工作。

目前的一般做法是加一个后台监控程序，轮询每一个网管进程的状态，如果发现某个进程不在了，那么就重新启动这个进程对应的可执行程序。但是这种方法只能解决进程异常退出的情景。实际工程中，某个进程可能会出现异常而不退出的情况，比如，进程存在内存泄露，一段时间后无法从系统成功申请新的内存；或者进程使用完毕后没有关闭一些系统资源，比如网络套接字，文件句柄，注册表访问句柄等，导致这些系统资源的再次申请失败。这些因系统资源申请而没有正确释放造成的后果是累积性的，在一段时间内不影响整个系统的正常工作，但是随着进程工作时间的增加，系统的负担也会逐渐加重，直到不能正常工作。而这些问题的定位往往比较困难，在定位前需要有一个应急的方法。

针对相关技术中系统资源申请没有得到释放造成的网管系统故障的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种网管系统中进程的恢复方法及装置，以至少解决相关技术中系统资源申请没有得到释放造成的网管系统故障的问题。

根据本发明的一个方面，提供了一种网管系统中进程的恢复方法，包括：按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；判断网管系统进程的系统资源申请量是否符合预设条件；以及在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。

进一步地，按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量包括：按照预设时间周期获取操作系统进程的系统资源申请量，将操作系统进程的系统资源申请量作为网管系统进程的系统资源申请量，其中，操作系统进程是与网管系统进程对应的。

进一步地，判断网管系统进程的系统资源申请量是否符合预设条件包括：判断网管系统进程的系统资源申请量是否达到预设门限；或者判断预设时间周期内网管系统进程的系统资源申请量的增长量是否达到预设增长量。

进一步地，重新启动网管系统进程包括：关闭网管系统进程，并加载网管系统进程对应的信息。

进一步地，网管系统进程对应的信息包括：网管系统进程的标识，网管系统进程的可执行文件，网管系统进程的启动信息以及网管系统进程对应的系统资源门限。

进一步地，重新启动网管系统进程包括：在与网管系统进程所对应的网管系统的空闲时段重新启动网管系统进程。

根据本发明的另一方面，提供了一种网管系统中进程的恢复装置，包括：获取模块，用于按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；判断模块，用于判断网管系统进程的系统资源申请量是否符合预设条件；以及重启模块，用于在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。

进一步地，获取模块包括：第一获取子模块，用于按照预设时间周期获取操作系统进程的系统资源申请量，将操作系统进程的系统资源申请量作为网管系统进程的系统资源申请量，其中，操作系统进程是与网管系统进程对应的。

进一步地，网管系统中进程的恢复装置还包括：更新模块，用于更新与网管系统进程对应的操作系统进程的标识，并建立网管系统进程与标识的对应关系。

通过本发明，采用实时监测网管系统进程的系统资源申请量的方式，能够及时发现当前占用过多系统资源的网管系统进程，从而找到潜在的异常的网管系统进程。通过将占用系统资源过多的网管系统进程重新启动，解决了相关技术中系统资源申请没有得到释放造成的网管系统故障的问题，进而达到了最大程度的保证网管系统可用性的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的网管系统中进程的恢复方法的流程图；

图2是根据本发明实施例的网管系统结构示意图；

图3是根据本发明实施例的网管系统结构布局示意图；以及

图4是根据本发明实施例的网管系统中进程的恢复装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在本实施例中提供了一种网管系统中进程的恢复方法，图1是根据本发明实施例的网管系统中进程的恢复方法的流程图，如图1所示，该流程包括如下步骤：

步骤S102，按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；

步骤S104，判断网管系统进程的系统资源申请量是否符合预设条件；

步骤S106，在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。

通过上述步骤，能够及时地发现网管系统中占用系统资源过多的网管系统进程，从而找到潜在异常的网管系统进程。通过重新启动占用系统资源过多的网管系统进程，解决了相关技术中系统资源申请没有得到释放造成的网管系统故障，达到了降低网管系统故障发生率，提高网管系统可用性的技术效果。

网管系统包括一个网络管理器和一个或者多个子网管理器，网络管理器进程协同一个或者多个子网管理器进程工作。图2是根据本发明实施例的网管系统结构示意图，如图2所示，网络管理器11的进程负责将消息转发至子网管理器21，22，23，并获取多个子网管理器的消息进行汇总上报。子网管理器21，22，23的进程分别负责管理各自子网内的网元。下面以图2中所示的网管系统具体说明该实施例的网管系统中进程的恢复方法，需要说明的是，本发明实施例中的网管系统中进程的恢复方法并不仅限于图2中所示的网管系统，对于其他结构的网管系统，本发明实施例的网管系统中进程的恢复方法同样适用。

可选地，本发明预先创建网管系统的监测模块，该监测模块可以用于执行上述步骤S102至步骤S106。图3是根据本发明实施例的网管系统结构布局示意图，如图3所示，该监测模块31用于实时监测网管系统中的网络管理器和子网管理器，其中，该监测模块31中预先配置有网管系统正常工作所需的网管系统进程列表以及网管系统进程列表中每个网管系统进程对应的信息。其中，网管系统中的网管系统进程包括网络管理器进程110，子网管理器进程210，220，230。

监测模块31为一个单独地用于监测网管系统进程的进程，对于不同的网管系统工程组网，需要对监测模块31配置相应的网管系统进程列表以及网管系统进程列表中每个网管系统进程对应的信息，以保证网管系统的正常工作。可选地，监测模块31中配置的内容包括：

网管系统进程列表，包括网络管理器进程110，子网管理器进程210，220，230。

网管系统进程列表中每个网管系统进程对应的信息包括：

网管系统进程的标识，比如网络管理器进程的标识为110，子网管理器进程的标识分别为210，220，230。

网管系统进程的可执行文件，为重新启动网管系统进程时加载的可执行程序的文件。通常情况下，不同设备类型的网元对应的子网管理器的可执行程序是不同的。比如，子网管理器21管理网元类型A的网元，使用的可执行程序的文件为A1.exe，子网管理器22和子网管理器23管理网元类型B的网元，使用的可执行程序的文件为B1.exe，网络管理器11管理所有的子网管理器，包括子网管理器21，子网管理器22和子网管理器23，使用的可执行程序的文件是C1.exe。

网管系统进程的启动信息，为重新启动网管系统进程时所需的启动信息，比如子网ID，网络监听端口号等。比如，网络管理器11不需要额外的启动信息，而子网管理器21，22，23需要各自的子网ID，假设分别为1201，1202，1203，用于通过子网ID获取各自管理的网元。

网管系统进程对应的系统资源门限，为网关系统进程允许的系统资源申请量的最大值，比如设置网管系统进程的系统资源门限为500M。该实施例假设只监测系统内存的资源申请量，对于其他的系统资源此处不再介绍，但是，该实施例的网管系统中进程的恢复方法同样可以适用。

在创建监测模块31，并配置好网管系统进程列表以及网管系统进程列表中每个网管系统进程对应的信息之后，该监测模块31开始执行步骤S102至步骤S106：

在执行步骤S102之前，监测模块31首先建立操作系统进程与网管系统进程的对应表，以便于在执行操作系统进程中对网管系统集成进行监测。其中，操作系统进程为网管系统所在的操作系统中的进程，比如Windiws操作系统。操作系统下包括多个操作系统进程，每个操作系统进程对应有唯一的操作系统进程标识。

可选地，建立操作系统进程与网管系统进程的对应表可以包括以下步骤：

监测模块31遍历当前操作系统下的所有操作系统进程：

当找到名称为C1.exe的进程时，即网络管理器进程110，记录此操作系统进程的标识，比如101；

当找到名称为A1.exe的进程时，即子网管理器进程210，记录此操作系统进程的标识，比如201；

当找到名称为B1.exe的进程时，即子网管理器进程220，230，记录此操作系统进程的标识，比如202，203。

要求每个操作系统进程上报自己的启动信息，即网管系统进程的启动信息，分别为网络管理器11不需要额外的启动信息，而子网管理器21，22，23需要各自的子网ID，分别为1201，1202，1203。

通过上述步骤，监测模块31建立了操作系统进程与网管系统进程的对应表，如表1所示，其中，表1为操作系统进程与网管系统进程的对应表。

表1

建立操作系统进程与网管系统进程的对应表，监测模块31通过定时监测操作系统进程101，201，202，203的系统资源申请量便可以实现对网管系统进程110，210，220，220的系统资源申请量的定时监测。可选地，步骤S102按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量包括：按照预设时间周期获取操作系统进程的系统资源申请量，将操作系统进程的系统资源申请量作为网管系统进程的系统资源申请量，其中，操作系统进程是与网管系统进程对应的，其对应关系可以如表1所示。

步骤S102中的预设时间周期可以根据实际需求设定，比如1个小时，10分钟，即每隔1小时或者10分钟获取一次网管系统进程在1小时或者10分钟内的系统资源申请量。网管系统进程在预设时间周期内的系统资源申请量是指在预设时间周期内，该网管系统进程申请的系统资源(比如内存)总量。监测模块31可以对不同的网管系统进程配置有不同的预设时间周期，也可以对不同系统资源配置有不同的预设时间周期。比如，如果需要获取网管系统内的其他系统资源，可以采取设定不同的时间周期，比如每2小时采集一次网管系统进程的文件同时打开的数量。获取操作系统进程的系统资源申请量一般是通过调用操作系统提供的应用函数接口来实现的，比如Windows操作系统下，获取系统资源(比如内存)申请量是通过使用操作系统进程ID作为输入参数，调用进程类应用过程接口函数来实现的。

监测模块31在执行步骤S102按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量之后，执行步骤S104。步骤S104中的预设条件可以判定网管系统进程的系统资源申请量，也可以判定网管系统进程的系统资源申请量的增长量。可选地，判断网管系统进程的系统资源申请量是否符合预设条件包括：判断网管系统进程的系统资源申请量是否达到预设门限；或者判断预设时间周期内网管系统进程的系统资源申请量的增长量是否达到预设增长量。其中，预设门限和预设增长量可以根据实际需求设定。

通过判断网管系统进程的系统资源申请量是否达到预设门限，或者通过多次的对比多次网管系统进程的系统资源申请的对比，能够分析出网管系统进程的系统资源申请量的增长量，从而找到潜在异常的网管系统进程。通过上述两种方式的判定，有利于提高对网管系统进程的系统资源申请量监测的准确度，进而达到准确分析网管系统故障可能性的技术效果。

在执行步骤S104判断网管系统进程的系统资源申请量是否符合预设条件之后，在判定在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程，即步骤S106。

当判定网管系统进程的系统资源申请量达到预设门限，或者预设时间周期内网管系统进程的系统资源申请量的增长量达到预设增长量时，重新启动该网管系统进程。

可选地，重新启动网管系统进程包括：关闭网管系统进程，并加载网管系统进程对应的信息。网管系统进程对应的信息。由于重新启动网管系统进程之后对应的操作系统进程的标识与未重新加载网管系统进程之前对应的操作系统进程的标识不同，所以，在重新启动网管系统进程之后，该实施例还包括：更新与网管系统进程对应的操作系统进程的标识，并重新建立网管系统进程与标识的对应关系。

比如，监测模块31监测到ID为101的操作系统进程，即网络管理器进程110的系统资源申请量(申请内存量)为502M，已经超过了预设门限500M，则关闭该ID为101对应的操作系统进程，即网络管理器进程110，并加载可执行文件C1.exe，由于没有额外的启动信息，则可以直接加载。由于加载后的进程ID往往与之前的进程ID 101不同，比如为102，监测模块31需要更新操作系统进程与网管系统进程的对应表，更新后的操作系统进程与网管系统进程的对应表如表2所示：

表2

再比如，监测模块31在连续的三个时间周期(时间周期为1小时)监测到进程ID为202的操作系统进程，即子网管理器进程220的系统资源申请量(内存申请量)分别为450M，460M，470M，则可以分析出该子网管理器进程220的内存申请量的每小时的增长量为10M，则3小时之后的系统资源申请量将会超过预设门限(500M)。如果当前时刻网管系统处于空闲时段，比如半夜12:00，则可以关闭该子网管理器进程220，并加载可执行文件B1.exe，加载启动信息子网ID 1202。同理，由于加载后的进程ID往往与之前的进程ID 202不同，比如为208，监测模块31需要更新操作系统进程与网管系统进程的对应表，更新后的操作系统进程与网管系统进程的对应表如表3所示：

表3

可选地，在判定网管系统进程的系统资源申请量达到预设门限，或者预设时间周期内网管系统进程的系统资源申请量的增长量达到预设增长量时，可以立即重新启动网管系统进程，或者，为了保证网管系统正常工作，可以不立即重新启动网管系统进程，而是在网管系统的空闲时段重新启动网管系统进程。对于当前预设时间周期内的网管系统进程的系统资源申请量为达到预设门限，但是通过分析其增长量，可以判定其在一段时间后会超过预设门限的情况，采用在网管系统空闲时段重新启动该网管系统进程，既有利于保证网管系统的正常工作，又能够及时发现网管系统潜在异常的网管系统进程，达到了最大程度地保证了网管系统的可用性的效果。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本实施例中还提供了一种网管系统中进程的恢复装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图4是根据本发明实施例的网管系统中进程的恢复装置的结构框图，如图4所示，该装置包括：

获取模块42，用于按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；

判断模块44，用于判断网管系统进程的系统资源申请量是否符合预设条件；

重启模块46，用于在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。

可选地，获取模块42包括：第一获取子模块，用于按照预设时间周期获取操作系统进程的系统资源申请量，将操作系统进程的系统资源申请量作为网管系统进程的系统资源申请量，其中，操作系统进程是与网管系统进程对应的。

可选地，判断模块44包括：第一判断子模块，用于判断网管系统进程的系统资源申请量是否达到预设门限；第二判断子模块，用于判断预设时间周期内网管系统进程的系统资源申请量的增长量是否达到预设增长量。

可选地，重启模块46包括：第一重启子模块模块，用于关闭网管系统进程，并加载网管系统进程对应的信息。其中，网管系统进程对应的信息包括：网管系统进程的标识，网管系统进程的可执行文件，网管系统进程的启动信息以及网管系统进程对应的系统资源门限。

可选地，重启模块46还可以包括：第二重启子模块，用于在与网管系统进程所对应的网管系统的空闲时段重新启动网管系统进程。

可选地，该实施例的网管系统中进程的恢复装置还包括：更新模块，用于更新与网管系统进程对应的操作系统进程的标识，并建立网管系统进程与标识的对应关系。

该实施例的网管系统中进程的恢复装置通过获取模块42按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量，通过判断模块44判断网管系统进程的系统资源申请量是否符合预设条件，通过重启模块46在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程，解决了相关技术中系统资源申请没有得到释放造成的网管系统故障，达到了降低网管系统故障发生率，提高网管系统可用性的技术效果。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：

S1，按照预设时间周期获取网管系统进程在预设时间周期内的系统资源申请量；

S2，判断网管系统进程的系统资源申请量是否符合预设条件；

S3，在判定网管系统进程的系统资源申请量符合预设条件时，重新启动网管系统进程。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种网管系统中进程的恢复方法，其特征在于，包括：

按照预设时间周期获取网管系统进程在所述预设时间周期内的系统资源申请量；

判断所述网管系统进程的系统资源申请量是否符合预设条件；以及

在判定所述网管系统进程的系统资源申请量符合所述预设条件时，重新启动所述网管系统进程。

2.根据权利要求1所述的方法，其特征在于，按照预设时间周期获取网管系统进程在所述预设时间周期内的系统资源申请量包括：

按照所述预设时间周期获取操作系统进程的系统资源申请量，将所述操作系统进程的系统资源申请量作为所述网管系统进程的系统资源申请量，其中，所述操作系统进程是与所述网管系统进程对应的。

3.根据权利要求2所述的方法，其特征在于，在重新启动所述网管系统进程之后，所述方法还包括：

更新与所述网管系统进程对应的操作系统进程的标识，并建立所述网管系统进程与所述标识的对应关系。

4.根据权利要求1所述的方法，其特征在于，判断所述网管系统进程的系统资源申请量是否符合预设条件包括：

判断所述网管系统进程的系统资源申请量是否达到预设门限；或者

判断所述预设时间周期内所述网管系统进程的系统资源申请量的增长量是否达到预设增长量。

5.根据权利要求1所述的方法，其特征在于，重新启动所述网管系统进程包括：

关闭所述网管系统进程，并加载所述网管系统进程对应的信息。

6.根据权利要求5所述的方法，其特征在于，所述网管系统进程对应的信息包括：

所述网管系统进程的标识，所述网管系统进程的可执行文件，所述网管系统进程的启动信息以及所述网管系统进程对应的系统资源门限。

7.根据权利要求1所述的方法，其特征在于，重新启动所述网管系统进程包括：

在与所述网管系统进程所对应的网管系统的空闲时段重新启动所述网管系统进程。

8.一种网管系统中进程的恢复装置，其特征在于，包括：

获取模块，用于按照预设时间周期获取网管系统进程在所述预设时间周期内的系统资源申请量；

判断模块，用于判断所述网管系统进程的系统资源申请量是否符合预设条件；以及

重启模块，用于在判定所述网管系统进程的系统资源申请量符合所述预设条件时，重新启动所述网管系统进程。

9.根据权利要求8所述的装置，其特征在于，所述获取模块包括：

第一获取子模块，用于按照所述预设时间周期获取操作系统进程的系统资源申请量，将所述操作系统进程的系统资源申请量作为所述网管系统进程的系统资源申请量，其中，所述操作系统进程是与所述网管系统进程对应的。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

更新模块，用于更新与所述网管系统进程对应的操作系统进程的标识，并建立所述网管系统进程与所述标识的对应关系。