CN115576725A - 一种内存故障管理方法、装置及存储介质 - Google Patents

Abstract

本申请公开了一种内存故障管理方法、装置及存储介质，涉及存储领域，可以有效降低计算设备上的业务因内存故障问题带来的影响。方法包括：确定第一计算设备的内存故障严重程度；内存故障严重程度是基于第一计算设备的运行日志包确定的；当第一计算设备的内存故障严重程度满足第一预设条件时，向第一计算设备发送业务迁移指令；业务迁移指令用于指示第一计算设备执行业务迁移。

Description

一种内存故障管理方法、装置及存储介质

技术领域

本申请涉及存储领域，尤其涉及一种内存故障管理方法、装置及存储介质。

背景技术

计算设备中的动态随机存取存储器(dynamic random access memory，DRAM)是常用的随机存取存储器，随着计算技术的发展，DRAM的容量越来越大，同时故障率也随之升高。

相关技术中，对于计算设备的内存故障，可以由集中运维平台通过标准的故障上报接口(例如redfish接口)定期向该平台所管理的计算设备收集内存故障信息，基于内存故障信息进行内存故障预测，并呈现告警。然而，有些计算设备没有定义标准的故障上报接口，无法对其进行内存故障预测；或者因标准故障上报接口协议限制，上述集中运维平台通过标准接口收集的故障信息不全面，导致集中运维管理平台无法进行全面准确的故障预测。同时，上述相关技术中，在实施内存故障预测后，并未提出有效的解决方案，因此，全面的预测内存故障并实施解决策略成为亟需解决的问题。

发明内容

本申请提供了一种内存故障管理方法、装置及存储介质，可以有效降低计算设备上的业务因内存故障问题带来的影响。

为实现上述技术目的，本申请采用如下技术方案：

第一方面，本申请提供了一种内存故障管理方法，应用于集中运维管理平台，该方法包括：确定第一计算设备的内存故障严重程度；内存故障严重程度是基于第一计算设备的运行日志包确定的；当第一计算设备的内存故障严重程度满足第一预设条件时，向第一计算设备发送业务迁移指令；业务迁移指令用于指示第一计算设备执行业务迁移。

可以理解的是，由于相关技术中在确定计算设备的内存故障严重程度后，没有对内存故障严重的计算设备执行业务迁移，因此，本申请在确定计算设备的内存故障严重程度后，及时对计算设备中内存故障严重程度满足第一预设条件的计算设备执行业务迁移，可以有效降低计算设备上的业务因内存故障问题带来的影响。

在一种可能的实现方式中，上述确定第一计算设备的内存故障严重程度前，该方法还包括：获取第一计算设备的运行日志包；对运行日志包进行解析，得到参数组数据；参数组数据包括第一计算设备的内存故障参数；将参数组数据输入内存故障预测模型，得到第一计算设备的内容故障预测结果；其中，内存故障预测结果用于表征内存故障严重程度。

可以理解的是，计算设备的运行日志包中包含所有内存故障信息，因此集中运维管理平台通过分析运行日志包，可以避免相关技术中获取内存故障信息不全面的问题，从而对计算设备的内存故障展开准确全面的预测。

在另一种可能的实现方式中，如果第一计算设备的内存故障严重程度大于等于第一阈值，则确定内存故障严重程度满足第一预设条件。

可以理解的是，当第一计算设备的内存故障严重程度大于第一阈值，表明该第一计算设备的内存故障严重程度较高，该方法能快速判断内存故障严重程度。

在另一种可能的实现方式中，集中运维管理平台管理多个计算设备；方法还包括：如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中最高，则确定内存故障严重程度满足第一预设条件；或者，如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中属于候选严重程度之一，则确定内存故障严重程度满足第一预设条件；其中，候选严重程度的个数是预设数量，且候选严重程度大于非候选严重程度。

可以理解的是，当有多个计算设备时，除了上述内存故障严重程度大于第一阈值的预设条件方法外，还可以基于多个计算设备的内存故障严重程度，优先对内存故障严重程度最高的，或者，优先对内存故障严重程度排名前几位的计算设备执行业务迁移。优先对内存故障严重程度最高或排名前几位的计算设备执行业务迁移，可以以最快的速度优先处理内存故障严重程度较为严重的计算设备，避免因集中运维平台管理的计算设备过多，而导致的部分内存故障严重程度较高的计算设备的业务迁移不及时的现象。

在另一种可能的实现方式中，业务迁移指令具体用于指示：将第一计算设备的业务迁移至第二计算设备；其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。

可以理解的是，本申请实施例在上述业务迁移指令具体指示的两种可选的方案中，优先选择内存故障严重程度较低且空闲容量较大的一个或多个计算设备，该方法不会给第二计算设备造成业务压力，同时能保证被迁移的业务可以稳定运行，减少再次被迁移的概率，提高迁移工作效率。

第二方面，本申请提供了一种内存故障管理方法，该方法应用于第一计算设备，该方法包括：接收集中运维管理平台发送的第一计算设备的内存故障严重程度；当内存故障严重程度满足第一预设条件时，执行业务迁移。

可以理解的是，该方法中，第一计算设备在内存故障严重程度较高时，将业务迁移，可以有效降低业务因内存故障问题带来的影响。同时，该方法中内存故障管理过程在第一计算设备中实施，可以减少集中运维管理平台的工作量，当集中运维管理平台管理的计算设备数量很多时，由于内存故障管理方法在每个计算设备中各自执行，因此可以提高内存故障管理效率。

在一种可能的实现方式中，第一预设条件包括：内存故障严重程度大于等于第一阈值。

可以理解的是，当第一计算设备的内存故障严重程度大于第一阈值，表明该第一计算设备的内存故障严重程度较高，该方法能快速判断内存故障严重程度。

在一种可能的实现方式中，执行业务迁移包括：将第一计算设备的业务迁移至第二计算设备；其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。

可以理解的是，本申请实施例在上述业务迁移指令具体指示的两种可选的方案中，优先选择内存故障严重程度较低且空闲容量较大的一个或多个计算设备，该方法不会给第二计算设备造成业务压力，同时能保证被迁移的业务可以稳定运行，减少再次被迁移的概率，提高迁移工作效率。

第三方面，本申请提供一种内存故障管理装置，该内存故障管理装置包括应用于第一方面或第一方面中任一种可能的设计方式的方法的各个模块；或者，该内存故障管理装置包括应用于第二方面或第二方面中任一种可能的设计方式的方法的各个模块。

第四方面，本申请提供一种内存故障管理装置，包括存储器和处理器。存储器和处理器耦合；存储器用于存储计算机程序代码，计算机程序代码包括计算机指令。当处理器执行该计算机指令时，使得该内存故障管理装置执行如第一方面及其任一种可能的实现方式的内存故障管理方法；或者，当处理器执行该计算机指令时，使得该内存故障管理装置执行如第二方面及其任一种可能的实现方式的内存故障管理方法。

第五方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令。其中，当计算机指令在内存故障管理装置上运行时，使得该内存故障管理装置执行如第一方面及其任一种可能的实现方式的内存故障管理方法；或者，当计算机指令在内存故障管理装置上运行时，使得该内存故障管理装置执行如第二方面及其任一种可能的实现方式的内存故障管理方法。

第六方面，本申请提供一种计算机程序产品，该计算机程序产品包括计算机指令。其中，当计算机指令在内存故障管理装置上运行时，使得该内存故障管理装置执行如第一方面及其任一种可能的实现方式的内存故障管理方法；或者，当计算机指令在内存故障管理装置上运行时，使得该内存故障管理装置执行如第二方面及其任一种可能的实现方式的内存故障管理方法。

本申请中第三方面到第六方面及其各种实现方式的具体描述，可以参考第一方面或第二方面及其各种实现方式中的详细描述；并且，第三方面到第六方面及其各种实现方式的有益效果，可以参考第一方面或第二方面及其各种实现方式中的有益效果分析，此处不再赘述。

本申请的这些方面或其他方面在以下的描述中会更加简明易懂。

附图说明

图1为本申请实施例提供的内存故障管理方法所涉及的一种实施环境示意图；

图2为本申请实施例提供的一种内存故障管理方法流程图；

图3为本申请实施例提供的另一种内存故障管理方法流程图；

图4为本申请实施例提供的一种内存故障管理装置的结构示意图；

图5为本申请实施例提供的另一种内存故障管理装置的结构示意图；

图6为本申请实施例提供的另一种内存故障管理装置的结构示意图。

具体实施方式

术语“第一”、“第二”和“第三”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”或“第三”等的特征可以明示或者隐含地包括一个或者更多个该特征。

计算设备中的DRAM是常用的随机存取存储器，随着计算技术的发展，DRAM的容量越来越大，同时故障率也随之升高。相关技术中，常用的方法是集中运维平台通过标准的故障上报接口(例如redfish接口)定期向该平台所管理的计算设备收集内存故障信息，基于内存故障信息进行内存故障预测，并呈现告警。

上述方案中，通过集中运维平台收集故障信息进行内存故障预测的方法，由于部分计算设备没有定义标准故障上报接口，无法对其进行内存故障预测；或者因标准故障上报接口协议限制，上述集中运维平台通过标准接口收集的故障信息不全面，导致集中运维管理平台无法进行全面准确的故障预测。同时，上述相关技术中，在实施内存故障预测后，并未提出有效的解决方案。

基于此，本申请实施例提出了一种内存故障管理方法，该方法中集中运维管理平台在得到管理的计算设备的内存故障严重程度后，对其中内存故障严重程度较高的计算设备执行业务迁移。可以理解的是，由于相关技术中在确定计算设备的内存故障严重程度后，没有对内存故障严重的计算设备执行业务迁移，因此，本申请在确定计算设备的内存故障严重程度后，及时对计算设备中内存故障严重程度满足第一预设条件的计算设备执行业务迁移，可以有效降低计算设备上的业务因内存故障问题带来的影响。

下面将结合附图对本申请实施例的实施方式进行详细描述。

请参考图1，其示出本申请实施例提供的一种内存故障管理方法所涉及的实施环境示意图。如图1所示，该实施环境可以包括：计算设备110和集中运维管理平台120。集中运维管理平台120可以管理多台计算设备110，本申请实施例对计算设备110的数量不做限定。

示例性的，计算设备110可以是终端，例如平板电脑、桌面型、膝上型、笔记本电脑和上网本等，还可以是服务器。本申请实施例对该计算设备110的具体形态不作特殊限制。

集中运维管理平台120包含内存故障预测模型121。集中运维管理平台120是一种集中管理和运维多个计算设备110的管理软件/工具/平台，可以用于为多个计算设备110(例如服务器)、存储等数据中心基础设施提供统一的故障收集、故障预警、故障上报、配置管理、设备管理、版本管理等功能。在本申请实施例中，集中运维管理平台120可以用于获取计算设备110的运行日志，并解析出用于进行内存故障预测的参数，然后，将该参数输入内存故障预测模型121，内存故障预测模型121输出内存故障预测结果，集中运维管理平台120基于该内存故障预测结果对多个计算设备110中满足第一预设条件的计算设备执行业务迁移。

示例性的，集中运维管理平台120可以是云服务化运维平台、集中式智能运维管理软件平台、云智能管理平台等。

示例性的，集中运维管理平台120可以是计算设备110中的软件，其可以安装在一台计算设备110上，或多台计算设备110上，共同实现对计算设备的内存故障管理的功能；也可以是独立于计算设备110之外的一个硬件设备。

下面将结合附图对本申请实施例的提出的内存故障管理方法进行详细描述。

请参考图2，为本申请实施例提供的一种内存故障管理方法流程图。如图2所示，该方法可以包括S101-S105。

S101：集中运维管理平台获取第一计算设备的运行日志包。

第一计算设备是集中运维管理平台管理的多个计算设备中的任意一个计算设备。

运行日志包是第一计算设备生成的任意一个或多个运行日志包，每个运行日志包记录了一个运行事件。

可选的，每隔预设时间段，集中运维管理平台获取第一计算设备的运行日志包。

预设时间段小于或等于阈值，一般的，此阈值时间较短，例如一天。该预设时间段的设置，有利于让集中运维管理平台及时分析获取的运行日志包，发现内存故障严重的计算设备，并对其进行管理。

可选的，集中运维管理平台向第一计算设备发送指示信息，指示信息用于指示获取运行日志包。第一计算设备接收到指示信息后，将运行日志包发送给集中运维管理平台，集中运维管理平台接收第一计算设备针对指示信息返回的运行日志包。

集中运维管理平台可以主动向计算设备获取运行日志包，也可以由外部工具导入计算设备的运行日志包。主动获取的方法，可以基于设置好的预设时间段向计算设备发送指示信息，避免人工干预，提高工作效率，便于后续及时对故障分析及管理。

集中运维管理平台可以一次获取一个计算设备的运行日志包，也可以一次批量获取多个计算设备的运行日志包。若有多个计算设备时，一次批量获取多个计算设备的运行日志包，可以提高获取效率。

S102：集中运维管理平台对运行日志包进行解析，得到参数组数据。

参数组数据包括第一计算设备的内存故障参数。

内存故障参数：是用于表征内存在运行过程中发生的故障的参数。

上述内存故障参数具体可以包括以下一项或多项内容，例如：可纠正错误(corrected error，CE)的类别、CE发生时间、CE出错次数、CE的物理地址信息、CE的系统地址信息、内存巡检出错次数、内存巡检出错行地址、内存巡检出错最多行地址、不可纠正错误的类型、不可纠正错误的状态、不可纠正错误的发生时间、不可纠正错误的出错次数、不可纠正错误的物理地址信息、不可纠正错误的物理地址信息、ECC纠错寄存器信息、机器检查体系(machine-check architecture，MCA)寄存器信息、MCA报告(report)信息、模式寄存器(mode register，MR)寄存器信息中的至少一种。

其中，上述CE的类别包括巡检可纠正错误、读写可纠正错误、搬移可纠正错误、镜像回写可纠正错误等。

其中，上述不可纠正错误的类型包括突发致命错误、选择处理(SW recoverableaction optional，SRAO)错误、不需要处理(uncorrected no action，UCNA)错误、必须处理(SW recoverable action required，SRAR)错误、巡检不可纠正错误等。

上述物理地址信息用于指示上述错误在上述内存中的物理位置，包括行地址信息、列地址信息、存储库(bank)地址信息、存储库组(bankgroup)地址信息、设备(device)地址信息、地址(address)寄存器信息、状态(status)寄存器、通道(channel)地址信息、rank地址信息、subrank地址信息、双列直插式存储模块标识(dual inline memory modulesidentity document，DIMM ID)信息、中央处理器标识(central processing unitidentity document，CPU ID)信息。

在一个示例中，集中运维管理平台对运行日志包解析后，得到参数组数据可以包含：CE的发生时间为xx年xx日xx时xx分、CE的出错次数为10次。

本申请实施例中，上述参数组数据包括但不限于上述内容。

S103：集中运维管理平台将参数组数据输入内存故障预测模型，得到第一计算设备的内容故障预测结果；其中，内存故障预测结果用于表征内存故障严重程度。

内存故障预测模型是一种基于参数组数据，对计算设备的内存进行评估的模型，该模型可以使用机器学习算法，包括但不限于如：随机森林、梯度提升决策树算法(gradient boosting decision tree，GBDT)、梯度提升决策树算法(extreme gradientboosting，xgboost)、朴素贝叶斯、SVM等机器学习算法；卷积神经网络(convolutionalneural networks,CNN)、长短期记忆模型(long-short term memory，LSTM)等深度学习算法；FedAvg、FedProx、FedCS等优化类算法，以及模型压缩、加密类算法等。该模型还可以使用分级阈值算法。

内存故障预测模型可以使用多种内存评估算法，但是机器学习算法可以针对内存的各项参数内容，例如：内存故障参数，综合对上述参数组数据进行评分，不同的内容对应不同的分值等级，运行状态越好得分越高，故障越多得分越低，以此来对内存故障严重程度进行评估，结果较为准确。

示例性的，内存故障预测模型通过参数组数据(例如CE出错次数为5次)，对计算设备内存故障严重程度进行评分，例如：满分100分制，该计算设备的内存总得分80分，分值越高表明内存状态越好；和/或，对计算设备内存故障严重程度进行等级区分，例如：严重程度一级，严重程度二级等，其中严重程度对应的等级越高表明内存状态越差。

在一个示例中，如表1所示，表1包含计算设备1中的运行日志包、参数组、参数组数据、每项具体信息评分和计算设备1的总分。

表1

在另一个示例中，如表2所示，表2包含计算设备2中的运行日志包、参数组、参数组数据、每项具体信息评分和计算设备2的总分。

表2

上述表1和表2为内存故障预测模型对不同计算设备中运行日志包进行评分的详细内容，通过表1和表2可知，不同计算设备的运行日志包解析出来的参数组数据各有不同，计算设备的评分也各有不同。

内存故障预测结果可以包含例如上述表1和表2中的计算设备的总分以及表中其他部分内容，可选的，内存故障预测结果还可以包含例如上述表1和表2中计算设备的总分对应的内存故障严重程度等级。

在一个示例中，如表3所示，表3示出内存故障预测模型输出的N台计算设备的内存故障预测结果，包含：计算设备名称、计算设备的总分和总分对应的内存故障严重程度。其中，与计算设备的总分对应的内存故障严重程度可以设置为：20分及以下严重程度十级，21～30分严重程度九级，31～40分严重程度八级，41～50分严重程度七级，51～60六级，61～70五级，71～80四季，81～90三级，91～95二级，95分及以上一级。

表3

计算设备名称	计算设备的总分	内存故障严重程度
			计算设备1	50	严重程度六级
计算设备2	60	严重程度五级
			…	…	…
计算设备N	95	严重程度一级

通过内存故障预测模型对多个计算设备的参数组数据进行评估，可以快速全面的评估多个计算设备的内存故障严重程度，获得各个计算设备的内存故障预测结果。

相关技术中，内存故障预测模型内置在计算设备内部，用于接收内存故障信息并进行故障评估。该技术中，内存故障预测模型只能用于单个计算设备，当一个机房中有多个计算设备，需要对内存故障预测模型进行升级时，需要依次对每个计算设备进行版本升级，操作麻烦，效率较低。

本申请实施例提出的内存故障管理方法中，内存故障预测模型设置在集中运维管理平台中，当集中运维管理平台控制多台计算设备时，如果需要升级内存故障预测模型，只需操作一次即可，简单高效。

S104：集中运维管理平台确定第一计算设备的内存故障严重程度。内存故障严重程度是基于第一计算设备的运行日志包确定的。

集中运维管理平台可以通过本申请S101-S103中方法中第一计算设备的内存故障预测结果来确定第一计算设备的内存故障严重程度，也可以通过现有技术的方法确定第一计算设备的内存故障严重程度，本申请实施例对如何得到内存故障严重程度的具体方法不做限定。

S105：当第一计算设备的内存故障严重程度满足第一预设条件时，集中运维管理平台向第一计算设备发送业务迁移指令。业务迁移指令用于指示第一计算设备执行业务迁移。

第一计算设备的内存故障严重程度满足第一预设条件，包括以下几种情况：

情况1、如果第一计算设备的内存故障严重程度大于等于第一阈值，则确定内存故障严重程度满足第一预设条件。

在一个示例中，假设内存故障严重程度用等级的方式来表示，等级越高故障严重程度越高，第一阈值的等级设为三级，若第一计算设备的内存故障严重程度为五级，五级大于三级，则内存故障严重程度满足第一预设条件。

情况2、集中运维管理平台管理多个计算设备；如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中最高，则确定内存故障严重程度满足第一预设条件。

在一个示例中，假设内存故障严重程度用等级的方式来表示，等级越高故障严重程度越高。集中运维管理平台管理了五个计算设备，该五个计算设备的内存故障严重程度分别为一级，二级，三级，四级，五级。若该五个计算设备中的第一计算设备的内存故障严重程度为五级(即内存故障严重程度最高)，则该第一计算设备的内存故障严重程度满足第一预设条件。

情况3、集中运维管理平台管理多个计算设备，如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中属于候选严重程度之一，则确定内存故障严重程度满足第一预设条件。

其中，候选严重程度的个数是预设数量，且候选严重程度大于非候选严重程度。

候选严重程度是内存故障严重程度中部分严重程度，该部分严重程度大于其他非候选严重程度。

在一个示例中，集中运维管理平台管理了五个计算设备，该五个计算设备的内存故障严重程度分别为一级，二级，三级，四级，五级。若候选严重程度的个数是三个，此时，三级，四级，五级为候选严重程度。若该5个计算设备中的第一计算设备的内存故障严重程度为三级，该第一计算设备的内存故障严重程度满足第一预设条件。

上述满足第一预设条件的几种情况中，当只有一个计算设备时，可以基于该计算设备的内存故障严重程度是否大于第一阈值来管理该计算设备是否执行业务迁移；当有多个计算设备时，除了情况1中的方法外，还可以基于多个计算设备的内存故障严重程度，优先对内存故障严重程度最高的，或者，优先对内存故障严重程度排名前几位的计算设备执行业务迁移。优先对内存故障严重程度最高或排名前几位的计算设备执行业务迁移，可以以最快的速度优先处理内存故障严重程度较为严重的计算设备，避免因集中运维平台管理的计算设备过多，而导致的部分内存故障严重程度较高的计算设备的业务迁移不及时的现象。

业务迁移指令具体用于指示：将第一计算设备的业务迁移至第二计算设备。

其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备。

或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。

第二计算设备可以是一个计算设备，也可以是集中运维管理平台管理的多个计算设备。

上述空闲内存容量满足第二预设条件的计算设备可以包括：集中运维管理平台管理的多个计算设备中，内存容量最大的一个计算设备，或者内存容量超过预设值的多个计算设备。

业务迁移的技术具体包括但不限于云系统中虚拟机热迁移、数据库高可用性(high availability，HA)技术等。

本申请实施例在上述业务迁移指令具体指示的两种可选的方案中，优先选择内存故障严重程度较低且空闲容量较大的一个或多个计算设备，该方法不会给第二计算设备造成业务压力，同时能保证被迁移的业务可以稳定运行，减少再次被迁移的概率，提高迁移工作效率。

本申请中集中运维管理平台及时对一个或多个计算设备中内存故障严重程度满足第一预设条件的计算设备执行业务迁移，可以有效降低计算设备上的业务因内存故障问题带来的影响，避免不必要的损失。

如图3所示，本申请实施例提供了另一种内存故障管理方法，方法包括S201-S203。

S201：集中运维管理平台向第一计算设备发送第一计算设备的内存故障严重程度。

集中运维管理平台确定内存故障严重程度方法参考上述S101-S103。

S202：第一计算设备接收集中运维管理平台发送的第一计算设备的内存故障严重程度。

S203：当内存故障严重程度满足第一预设条件时，第一计算设备执行业务迁移。

第一预设条件包括：内存故障严重程度大于等于第一阈值。

执行业务迁移包括：将第一计算设备的业务迁移至第二计算设备。

其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；

或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。

第二计算设备可以是一个计算设备，也可以是集中运维管理平台管理的多个计算设备。

上述空闲内存容量满足第二预设条件的计算设备可以包括：集中运维管理平台管理的多个计算设备中，内存容量最大的一个计算设备，或者内存容量超过预设值的多个计算设备。

业务迁移的技术具体包括但不限于云系统中虚拟机热迁移、数据库高可用性(high availability，HA)技术等。

在本申请实施例提供的另一种内存故障管理方法中，第一计算设备在内存故障严重程度较高时，将业务迁移，可以有效降低业务因内存故障问题带来的影响。同时，该方法中内存故障管理过程在第一计算设备中实施，可以减少集中运维管理平台的工作量，当集中运维管理平台管理的计算设备数量很多时，由于内存故障管理方法在每个计算设备中各自执行，因此可以提高内存故障管理效率。

上述主要从方法的角度对本申请实施例提供的方案进行了介绍。为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例还提供一种内存故障管理装置200，例如集中运维管理平台。如图4所示，为本申请实施例提供的一种内存故障管理装置200的结构示意图。

内存故障管理装置200包括：确定单元201，用于确定第一计算设备的内存故障严重程度；内存故障严重程度是基于第一计算设备的运行日志包确定的；发送单元202，用于当第一计算设备的内存故障严重程度满足第一预设条件时，向第一计算设备发送业务迁移指令；业务迁移指令用于指示第一计算设备执行业务迁移。例如，结合图2，确定单元201用于方法实施例中的S104，发送单元202用于方法实施例中的S105。

可选的，内存故障管理装置200还包括获取单元203，用于获取第一计算设备的运行日志包；内存故障管理装置200还包括日志解析单元204，用于对运行日志包进行解析，得到参数组数据；参数组数据包括第一计算设备的内存故障参数；内存故障管理装置200还包括输入单元205，用于将参数组数据输入内存故障预测模型，得到第一计算设备的内容故障预测结果；其中，内存故障预测结果用于表征内存故障严重程度。例如，结合图2，获取单元203用于方法实施例中的S101，日志解析单元204用于方法实施例中的S102，输入单元205用于方法实施例中的S103。

可选的，确定单元201还用于，如果第一计算设备的内存故障严重程度大于等于第一阈值，则确定内存故障严重程度满足第一预设条件。例如，结合图2，确定单元201用于方法实施例中的S105。

可选的，集中运维管理平台管理多个计算设备；确定单元201还用于，如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中最高，则确定内存故障严重程度满足第一预设条件；或者，如果第一计算设备的内存故障严重程度，在多个计算设备的内存故障严重程度中属于候选严重程度之一，则确定内存故障严重程度满足第一预设条件；其中，候选严重程度的个数是预设数量，且候选严重程度大于非候选严重程度。例如，结合图2，确定单元201用于方法实施例中的S105。

可选的，业务迁移指令具体用于指示：将第一计算设备的业务迁移至第二计算设备；其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。例如，结合图2，确定单元201用于方法实施例中的S105。

当然，本申请实施例提供的内存故障管理装置200包括但不限于上述模块。

本申请实施例还提供一种内存故障管理装置300，例如第一计算设备。如图5所示，为本申请实施例提供的一种内存故障管理装置300的结构示意图。

内存故障管理装置300包括：接收单元301，用于接收集中运维管理平台发送的第一计算设备的内存故障严重程度；业务迁移单元302，用于当内存故障严重程度满足第一预设条件时，执行业务迁移。例如，结合图3，接收单元301用于方法实施例中的S202。

可选的，第一预设条件包括：内存故障严重程度大于等于第一阈值。

可选的，业务迁移单元302具体用于，将第一计算设备的业务迁移至第二计算设备；其中，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；或者，第二计算设备是集中运维管理平台管理的多个计算设备中内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，多个计算设备中除第一计算设备之外的计算设备满足负载均衡。例如，结合图3，接收单元301用于方法实施例中的S203。

当然，本申请实施例提供的内存故障管理装置300包括但不限于上述模块。

图6是本申请实施例提供的另一种内存故障管理装置400的结构示意图，该内存故障管理装置400可以是如计算设备、平板电脑、桌面型、膝上型、笔记本电脑和上网本等计算设备。如图6所示，该内存故障管理装置400包括处理器401、存储器402和网络接口403。

其中，处理器401包括一个或多个CPU。该CPU可以为单核CPU(single-CPU)或多核CPU(multi-CPU)。

存储器402包括但不限于是随机存取存储器(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmableread-only memory，EPROM)、快闪存储器、或光存储器等。

可选地，处理器401通过读取存储器402中保存的指令实现本申请实施例提供的内存故障管理方法，或者，处理器401通过内部存储的指令实现本申请实施例提供的内存故障管理方法。在处理器401通过读取存储器402中保存的指令实现上述实施例中的方法的情况下，存储器402中保存实现本申请实施例提供的内存故障管理方法的指令。

网络接口403，包含发送器和接收器的一类装置，用于与其他设备或通信网络通信，可以是有线接口(端口)，例如光纤分布式数据接口(fiber distributed datainterface，FDDI)、千兆以太网接口(gigabit ethernet，GE)。或者，网络接口403是无线接口。应理解，网络接口403包括多个物理端口，网络接口403用于通信等。

可选地，内存故障管理装置400还包括总线404，上述处理器401、存储器402、网络接口403通常通过总线404相互连接，或采用其他方式相互连接。

在实际实现时，上述确定单元201、发送单元202、获取单元203、日志解析单元204和输入单元205，以及上述接收单元301和业务迁移单元302，可以由处理器调用存储器中的计算机程序代码来实现。其具体的执行过程可参考上述方法部分的描述，这里不再赘述。

本申请另一实施例还提供一种内存故障管理装置，内存故障管理装置可以是如计算设备、平板电脑、桌面型、膝上型、笔记本电脑和上网本等计算设备。该内存故障管理装置包括存储器和处理器。存储器和处理器耦合；存储器用于存储计算机程序代码，计算机程序代码包括计算机指令。其中，当处理器执行该计算机指令时，使得该内存故障管理装置执行上述方法实施例所示的内存故障管理方法的各个步骤。

本申请另一实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当计算机指令在内存故障管理装置上运行时，使得内存故障管理装置执行上述方法实施例所示的内存故障管理方法流程中内存故障管理装置执行的各个步骤。

本申请另一实施例还提供一种芯片系统，该芯片系统应用于内存故障管理装置。该芯片系统包括一个或多个接口电路，以及一个或多个处理器。接口电路和处理器通过线路互联。接口电路用于从内存故障管理装置的存储器接收信号，并向处理器发送信号，信号包括存储器中存储的计算机指令。当内存故障管理装置处理器执行计算机指令时，内存故障管理装置执行上述方法实施例所示的内存故障管理处理方法流程中内存故障管理装置执行的各个步骤。

在本申请另一实施例中还提供一种计算机程序产品，该计算机程序产品包括计算机指令，当计算机指令在内存故障管理装置上运行时，使得内存故障管理装置执行上述方法实施例所示的内存故障管理方法流程中内存故障管理装置执行的各个步骤。

上述实施例可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，上述实施例可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机执行指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、服务器或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

以上所述，仅为本申请的具体实施方式。熟悉本技术领域的技术人员根据本申请提供的具体实施方式，可想到变化或替换，都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种内存故障管理方法，其特征在于，应用于集中运维管理平台，所述方法包括：

确定第一计算设备的内存故障严重程度；所述内存故障严重程度是基于所述第一计算设备的运行日志包确定的；

当所述第一计算设备的内存故障严重程度满足第一预设条件时，向所述第一计算设备发送业务迁移指令；所述业务迁移指令用于指示所述第一计算设备执行业务迁移。

2.根据权利要求1所述的方法，其特征在于，所述确定第一计算设备的内存故障严重程度前，所述方法还包括：

获取所述第一计算设备的所述运行日志包；

对所述运行日志包进行解析，得到参数组数据；所述参数组数据包括所述第一计算设备的内存故障参数；

将所述参数组数据输入内存故障预测模型，得到所述第一计算设备的内存故障预测结果；其中，所述内存故障预测结果用于表征所述内存故障严重程度。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果所述第一计算设备的内存故障严重程度大于等于第一阈值，则确定所述内存故障严重程度满足所述第一预设条件。

4.根据权利要求1所述的方法，其特征在于，所述集中运维管理平台管理多个计算设备；所述方法还包括：

如果所述第一计算设备的内存故障严重程度，在所述多个计算设备的内存故障严重程度中最高，则确定所述内存故障严重程度满足所述第一预设条件；

或者，如果所述第一计算设备的内存故障严重程度，在所述多个计算设备的内存故障严重程度中属于候选严重程度之一，则确定所述内存故障严重程度满足所述第一预设条件；其中，所述候选严重程度的个数是预设数量，且所述候选严重程度大于非候选严重程度。

5.根据权利要求1至4任一项所述的方法，其特征在于，

所述业务迁移指令具体用于指示：将所述第一计算设备的业务迁移至第二计算设备；

其中，所述第二计算设备是所述集中运维管理平台管理的多个计算设备中所述内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；

或者，所述第二计算设备是所述集中运维管理平台管理的多个计算设备中所述内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，所述多个计算设备中除所述第一计算设备之外的计算设备满足负载均衡。

6.一种内存故障管理方法，其特征在于，应用于第一计算设备，所述方法包括：

接收集中运维管理平台发送的所述第一计算设备的内存故障严重程度；

当所述内存故障严重程度满足第一预设条件时，执行业务迁移。

7.根据权利要求6所述的方法，其特征在于，所述第一预设条件包括：所述内存故障严重程度大于等于第一阈值。

8.根据权利要求6或7所述的方法，其特征在于，所述执行业务迁移包括：

将所述第一计算设备的业务迁移至第二计算设备；

其中，所述第二计算设备是所述集中运维管理平台管理的多个计算设备中所述内存故障严重程度低于第二阈值，且空闲内存容量满足第二预设条件的计算设备；

或者，所述第二计算设备是所述集中运维管理平台管理的多个计算设备中所述内存故障严重程度低于第二阈值的计算设备，且执行业务迁移后，所述多个计算设备中除所述第一计算设备之外的计算设备满足负载均衡。

9.一种内存故障管理装置，其特征在于，包括存储器和处理器；所述存储器和所述处理器耦合；所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；其中，当所述处理器执行所述计算机指令时，使得所述内存故障管理装置执行如权利要求1-8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令；其中，当所述计算机指令在内存故障管理装置上运行时，使得所述内存故障管理装置执行如权利要求1-8中任一项所述的方法。

Images