一种故障修复方法、装置及存储介质与流程

1.本技术实施例涉及计算机技术领域，尤其涉及一种故障修复方法、装置及存储介质。


背景技术：

2.随着互联网技术的广泛应用，内存的可靠性已成为各大企业关注的重点。经数据统计发现，内存中的行(row)故障是降低内存可靠性和引发服务器宕机的因素之一；一种处理行故障的方法是基于行替换(post-package repair，ppr)的方式。
3.然而，目前的基于ppr处理行故障的过程中，修复的行故障可能并不是引发服务器宕机的行故障，而由于内存中的冗余存储区域的可用资源量的限制，所以真正导致服务器宕机的行故障可能并未被修复，因此，降低了内存的可靠性。
4.因此，如何对行故障修复能提升内存的可靠性是本领域技术人员亟待解决的问题。


技术实现要素：

5.本技术实施例提供一种故障修复方法、装置及存储介质，能够提高内存的可靠性。
6.为达到上述目的，本技术实施例采用如下技术方案：
7.第一方面，本技术实施例提供一种故障修复方法，该方法包括：获取内存的第一行故障地址和第二行故障地址，第一行故障地址和第二行故障地址不同；该第一行故障地址指示了内存中发生故障的第一行故障位置，该第二行故障地址指示了内存中发生故障的第二行故障位置；确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度；依次对该第一行故障位置和第二行故障位置进行修复，该第一行故障位置的严重程度高于第二行故障位置的严重程度。
8.相比传统的按照多个行故障的发生时间依次对该多个行故障位置进行修复的方式，其中，发生时间越靠前的行故障位置，越先被修复；本技术实施例提供的故障修复方法是按照第一行故障位置和第二行故障位置的故障严重程度对该第一行故障位置和第二行故障位置进行修复的，其中，故障严重程度越高的行故障位置被优先进行修复；从而避免了因内存中严重程度较高的行故障位置被晚修复或不被修复，从导致的系统出现宕机的情况；因此提高了内存的可靠性。
9.一种可能的实现方式中，上述确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，包括：获取在预设时间段内发生在上述第一行故障位置的故障次数，和发生在第二行故障位置的故障次数；将第一行故障位置的故障次数输入至评估模型，得到该第一行故障位置的评分；第一行故障的评分用于表征第一行故障位置的故障严重程度；将第二行故障地址的故障次数输入至上述评估模型，得到第二行故障地址的评分；第二行故障的评分用于表征第二行故障位置的故障严重程度。
10.一种可能的实现方式中，上述预设时间段是从内存所在的计算设备上一次重启的
时间开始至计算设备本次重启的时间结束的时间。
11.一种可能的实现方式中，在上述确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度之后，该方法还包括：基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表；该目标故障列表中的行故障位置是按照行故障位置的故障严重程度大小进行排序的；上述依次对第一行故障位置和第二行故障位置进行修复，包括：按照上述目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复。
12.本技术实施例提供的故障修复方法，通过将第一行故障位置和第二行故障位置按照故障严重程度大小进行排序后得到目标故障列表；然后，在执行修复动作时，只需要根据目标故障列表中的行故障位置的排序，对该目标故障列表中的行故障位置按照故障严重程度由大到小的顺序依次进行修复，并不需要将每个行故障位置的故障严重程度与其他行故障位置的故障严重程度进行对比，因此，提高了行故障的修复效率。
13.一种可能的实现方式中，上述基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表，包括：当服务器在运行阶段时，基于该第一行故障位置的故障严重程度和该第二行故障位置的故障严重程度，确定目标故障列表；上述按照目标故障列表中的行故障位置的排序，依次对上述目标故障列表中的行故障位置进行修复，包括：当上述服务器在重启阶段时，按照目标故障列表中的行故障位置的排序，依次对该目标故障列表中的行故障位置进行修复。
14.本技术实施例在服务器运行阶段确定目标故障列表，所以在服务器重启阶段只需要根据目标故障列表中的行故障位置的排序依次对目标故障列表中的行故障位置进行修复，并不需要对该多个行故障位置根据严重程度进行排序，因此，提高了服务器的重启效率。
15.一种可能的实现方式中，上述在基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表之后，该方法还包括：根据第三行故障位置更新目标故障列表，得到更新后的目标故障列表；其中，第三行故障为上述预设时间段内发生的行故障，且第三行故障的发生时间在第一行故障和第二行故障的发生时间之后；该更新后的目标故障列表中的行故障位置是按照行故障位置的故障严重程度大小进行排序的；上述按照目标故障列表中的行故障位置的排序，依次对该目标故障列表中的行故障位置进行修复，包括：按照该更新后的目标故障列表中的行故障位置的排序，依次对更新后的目标故障列表中的行故障位置进行修复。
16.一种可能的实现方式中，上述根据第三行故障位置的故障严重程度更新目标故障列表，包括：当第三行故障位置与上述第一行故障位置和第二行故障位置均不同时，将该第三行故障位置添加进上述目标故障列表，得到更新后的目标故障列表；当该第三行故障位置与上述目标故障列表中的目标行故障位置相同时，更新该目标行故障位置的故障次数，并根据更新后的目标行故障位置的故障次数重新计算该目标行故障位置的故障严重程度；根据该目标行故障位置的故障严重程度和非目标行故障位置的故障严重程度，更新上述目标故障列表，得到更新后的目标故障列表，该非目标行故障位置为上述目标故障列表中除目标行故障位置以外的行故障位置。
17.第二方面，本技术实施例提供一种故障修复装置，该故障修复装置包括：获取模
块、确定模块和修复模块；上述获取模块用于获取内存的第一行故障地址和第二行故障地址，第一行故障地址和第二行故障地址不同；该第一行故障地址指示了内存中发生故障的第一行故障位置，该第二行故障地址指示了内存中发生故障的第二行故障位置；上述确定模块用于确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度；上述修复模块用于依次对上述第一行故障位置和第二行故障位置进行修复，该第一行故障位置的严重程度高于上述第二行故障位置的严重程度。
18.一种可能的实现方式中，获取模块用于获取在预设时间段内发生在第一行故障位置的故障次数，和发生在第二行故障位置的故障次数；上述确定模块用于将第一行故障位置的故障次数输入至评估模型，得到第一行故障位置的评分；第一行故障的评分用于表征第一行故障位置的故障严重程度；上述确定模块还用于将第二行故障地址的故障次数输入至评估模型，得到第二行故障地址的评分；第二行故障的评分用于表征第二行故障位置的故障严重程度。
19.一种可能的实现方式中，上述预设时间段是从内存所在的计算设备上一次重启的时间开始至计算设备本次重启的时间结束的时间。
20.一种可能的实现方式中，上述确定模块用于基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表；目标故障列表中的行故障位置是按照行故障位置的故障严重程度大小进行排序的；上述修改模块用于按照目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复。
21.一种可能的实现方式中，当服务器在运行阶段时，上述确定模块用于基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表；当服务器在重启阶段时，上述修复模块用于按照目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复。
22.一种可能的实现方式中，上述故障修复装置还包括：更新模块；更新模块用于根据第三行故障位置更新目标故障列表，得到更新后的目标故障列表；其中，第三行故障为预设时间段内发生的行故障，且第三行故障的发生时间在第一行故障和第二行故障的发生时间之后；更新后的目标故障列表中的行故障位置是按照行故障位置的故障严重程度大小进行排序的；上述修复模块用于按照更新后的目标故障列表中的行故障位置的排序，依次对更新后的目标故障列表中的行故障位置进行修复。
23.一种可能的实现方式中，上述更新模块用于当第三行故障位置与第一行故障位置和第二行故障位置均不同时，将第三行故障位置添加进目标故障列表，得到更新后的目标故障列表；上述更新模块用于当第三行故障位置与目标故障列表中的目标行故障位置相同时，更新目标行故障位置的故障次数，并根据更新后的目标行故障位置的故障次数重新计算目标行故障位置的故障严重程度；上述更新模块还用于根据目标行故障位置的故障严重程度和非目标行故障位置的故障严重程度，更新目标故障列表，得到更新后的目标故障列表，非目标行故障位置为目标故障列表中除目标行故障位置以外的行故障位置。
24.第三方面，本技术实施例提供一种计算设备，包括存储器和处理器，存储器与处理器耦合；存储器用于存储计算机程序代码，其中，计算机程序代码包括计算机指令；当计算机指令被处理器执行时，使得计算设备执行第一方面及其可能的实现方式中任意之一所述的方法。
25.第四方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机指令，当计算机指令在计算设备上运行时，使得计算设备执行上述第一方面及其可能的实现方式中任意之一所述的方法。
26.第五方面，本技术实施例提供一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面及其可能的实现方式中任意之一所述的方法。
27.应当理解的是，本技术实施例的第二方面至第五方面技术方案及对应的可能的实施方式所取得的有益效果可以参见上述对第一方面及其对应的可能的实施方式的技术效果，此处不再赘述。
附图说明
28.图1为本技术实施例提供的一种服务器的层级结构示意图；
29.图2为本技术实施例提供的一种服务器硬件结构示意图；
30.图3为本技术实施例提供的一种故障修复方法流程示意图一；
31.图4为本技术实施例提供的一种行故障与重启时间关系示意图；
32.图5为本技术实施例提供的一种内存结构示意图；
33.图6为本技术实施例提供的一种故障修复方法流程示意图二；
34.图7为本技术实施例提供的一种故障修复方法流程示意图三；
35.图8为本技术实施例提供的一种故障修复方法流程示意图三；
36.图9为本技术实施例提供的一种更新故障列表的方法流程示意图；
37.图10为本技术实施例提供的一种故障修复装置结构示意图。
具体实施方式
38.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
39.本技术实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一行故障和第二行故障是用于区别不同的行故障，而不是用于描述行故障的特定顺序。
40.在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
41.本技术实施例描述的架构场景是为了更加清楚的说明本技术实施例的技术方案，并不构成对于本技术实施例提供的技术方案的限定，本领域普通技术人员可知，随着计算机系统的演变，本技术实施例提供的技术方案对于类似的技术问题，同样适用。
42.随着互联网技术的广泛应用，内存的可靠性已成为各大企业关注的重点。经数据统计发现，内存中的行(row)故障是降低内存可靠性和引发服务器宕机的因素之一；传统的处理行故障的方式为基于封装后修复(post-package repair，ppr)的方式。
43.众所周知，上述ppr的方式是使用内存中的冗余存储区域替换存储区域中发生故障的区域；其中，存储区域用于存储数据，冗余存储区域用于替换存储区域中发生故障的区
域。
44.传统的基于ppr处理行故障的具体过程包括：服务器中的单板管理控制器(baseboard management controller，bmc)对接收到的多个行故障按照该多个行故障的发生时间进行排序，进而得到行故障列表。当服务器重启阶段，服务器中的基本输入输出系统(basic input output system，bios)，从bmc中获取该行故障列表，并按照行故障列表中的多个行故障的排序依次对该多个行故障进行ppr处理，直至服务器内存中的冗余存储区域的可用资源不足时结束修复行故障动作。
45.然而，传统的基于ppr处理行故障的过程中，修复的行故障可能并不是引发服务器宕机的行故障，而由于内存中的冗余存储区域的可用资源量的限制，所以真正导致服务器宕机的行故障可能并未被修复，从而降低了内存的可靠性。因此，如何对行故障修复能提升内存的可靠性是本领域技术人员亟待解决的问题。
46.基于此，本技术实施例提供了一种故障修复方法，该方法根据确定第一行故障位置和第二行故障位置的故障严重程度，对故障严重程度较高的第一行故障位置优先进行修复，从而避免了因内存中故障严重程度较高的行故障位置被晚修复或不被修复，从导致的系统出现宕机的情况；因此提高了内存的可靠性。
47.首先对本技术实施例提供的一种故障修复方法、装置及存储介质中涉及的一些概念做解释说明：
48.行故障：为内存中行(row)发生的可纠正错误(corrected error，ce)的故障或不可纠正错误(uncorrected error，uce)的故障，其中，内存的物理粒度从大到小依次为：dimm、rank、device、bank、row/column、cell、bit；其该多个物理粒度之间的关系具体为：每个计算机设备可以包括多个内存条(dimm)，每个内存条上具有两个内存列(rank)，分别位于内存的两个面，例如，两个内存列分别为内存列0(rank0)和内存列1(rank1)。其中，每个内存列上可以配置多个内存芯片(chip)用于存储数据，内存芯片也可以称为内存颗粒(device)，内存芯片可以是动态随机存取存储器(dynamic random access memory，dram)、静态随机存取存储器(static random access memory，sram)等，每个内存芯片可以划分为多个存储阵列(bank)，内存芯片在存储数据时，该数据以位(bit)为单位写入一个存储阵列中。另外，还可以将多个存储阵列归为一个存储阵列组(bankgroup)，其中，每个存储阵列组的存储阵列的数量可以相同，或者，也可以不同。存储阵列由大量的存储单元(cell)组成，大量的存储单元排列成二维矩阵形式，只要指定存储阵列上的行(row)和列(column)，则可以在存储阵列上定位一个存储单元，内存发生故障的最小单位为存储阵列上的存储单元。也就是说，内存故障包括：dimm故障、rank故障、device故障、bank故障、row故障/column故障、cell故障以及bit故障中的至少一种。
49.服务器包括硬件层和软件层，软件层是运行在硬件层上的程序代码。软件层又可以分成若干个层，层与层之间通过软件接口通信。软件层从上至下包括应用层、“操作系统(operating system，os)和基本输入输出系统(basic input output system，bios)”、驱动层以及硬件层，如图1所示。
50.应用层，包括一系列运行应用程序的程序代码。
51.os，是运行在cpu中的系统。该os系统可以是linux、windows或vxworks等。
52.bios，是加载在bios芯片中的系统，用来设置硬件，为os运行做准备。bios的主要
功能是上电、自检、cpu初始化、内存初始化、检测输入输出设备以及可启动设备并最终引导os启动。
53.驱动层，包括板机支持包和驱动程序，其用于为应用层、os和bios提供操作硬件层中的装置接口；也就是说，驱动层是“应用层、os和bios与硬件层的衔接层。
54.硬件层，包括处理器(central processing unit，cpu)101、存储器102、bios芯片103以及单板管理控制器(baseboard management controller，bmc)芯片104等计算机硬件。这些硬件之间的连接关系如图2所示。
55.图2是本技术实施例提供的一种服务器的硬件结构示意图，该服务器可以是支持内存ppr技术的任意类型的服务器，例如x86架构的服务器，具体可以是刀片服务器、高密服务器、机架服务器或高性能服务器等，其中，该服务器包括处理器201、存储器202、网络接口203、总线204、bois芯片205以及bmc芯片206。
56.其中，处理器201可以包括一个或多个处理单元，例如：处理器201可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
57.存储器202用于存储数据，其中该存储器202包括但不限于是随机存取存储器(random access memory，ram)、只读存储器(read-only memory，rom)、快闪存储器、或光存储器等。
58.该存储器202用于与上述处理器201交互，并将交互过程中产生的故障信息发送至bios芯片205；其中该存储器202中包括至少一个内存。
59.网络接口203是有线接口(端口)，例如fddi、ge接口。或者，网络接口203是无线接口。应理解，网络接口203包括多个物理端口，网络接口203用于获取第一行故障地址和第二行故障地址等。
60.总线204，上述处理器201、存储器202、网络接口203、biso芯片205以及bmc芯片206通常通过总线204相互连接，或采用其他方式相互连接。
61.bios芯片205可以用于检测内存行故障，例如，确定该行故障为可以纠正错误的相关信息或不可纠正错误的相关信息等。需要说明的是，上述内存的行故障的具体内容仅是示例性的举例，本技术实施例对于bios芯片205检测的行故障的具体内容并不限定。需要说明的是，内存中每一个行故障是由多个bit故障和/或cell故障导致的；也就是说，当内存中bit故障和/或cell故障的数量达到阈值时，内存会上报一个行故障。
62.bmc芯片206可以通过专用的数据通道对服务器进行远程维护和管理，该bmc是完全独立于服务器的os之外的，可以通过服务器的带外管理接口与上述bios和os进行通信。
63.需要说明的是，执行本技术实施例提供的故障修复方法的装置可以是上述图2所示的服务器中的bios芯片205或bmc芯片206。或者，上述图2所示的服务器中的bmc芯片206执行下述s310-s320，bios芯片205执行下述s330。
64.本技术实施例提供的一种故障修复方法，如图3所示，该方法可以包括s310-s330。
65.s310、故障修复装置获取内存的第一行故障地址和第二行故障地址。
66.上述行故障为预设时间段内内存中行(row)发生的可纠正错误(corrected error，ce)的故障；其中，预设时间段是从内存所在的计算设备上一次重启的时间开始至该计算设备本次重启的时间结束的时间段。
67.示例性的，如图4所示，点0为计算设备(如：服务器)第一次发生重启的时间，点e为服务器第二次(即本次)发生重启的时间；点a-d为服务器的内存在第一次重启后与第二次重启前发生的4个行故障。其中，上述预设时间段指示图4中的点0至点e的这段时间段；上述多个行故障为点a-d对应的行故障a-d。
68.应理解的是，上述获取行故障地址之前，可以根据当前故障的类型确定当前故障是否为行故障，其中，故障的类型包括：行故障、列故障、比特故障以及rank故障等内存物理粒度的故障。还可以根据当前故障的故障地址确定当前故障是否为行故障，当前故障的故障地址的最后一位为内存物理粒度中的行时，当前故障为行故障；否则，当前故障为非行故障；例如，当前行故障地址为“cpu1.chn0.dimm1.rank1.dev1.bank1.row0”；因为，该地址的最后一位为“row”(即：内存物理粒度中的行)，所以当前故障为行故障；又例如，当前行故障地址为“cpu1.chn0.dimm1.rank1.dev1.bank1”因为，该地址的最后一位为“bank”(即：内存物理粒度中的bank)，所以当前故障为非行故障。然后在确定至少两个行故障后，在从该至少两个行故障中获取第一行故障地址和第二行故障地址。
69.需要说明的是，第一行故障地址和第二行故障地址不同；第一行故障地址指示了内存中发生故障的第一行故障位置，第二行故障地址指示了内存中发生故障的第二行故障位置。
70.应理解的是，上述故障修复装置可以是仅获取第一行故障地址和第二行故障地址，也可以是获取多个行故障地址，其中，该多个行故障地址中包括第一行故障地址和第二行故障地址。
71.示例性的，假设上述多个行故障地址包括：第一行故障地址和第二行故障地址；其中，第一行故障地址为“cpu1.chn0.dimm1.rank1.dev1.bank1.row0”；第二行故障地址为“cpu1.chn0.dimm1.rank1.dev1.bank1.row1”。其中，第一行故障地址“cpu1.chn0.dimm1.rank1.dev.
72.bank1.row0”用于指示内存中“cpu1.chn0.dimm1.rank1.dev1.bank1”这个位置中的row0发生ce故障；第二行故障地址“cpu1.chn0.dimm1.rank1.dev1.bank1.row1”用于指示内存中“cpu1.chn0.dimm1.rank1.dev1.bank1”这个位置中的row1发生ce故障。
73.需要说明的是，上述s310中故障修复装置可以从其他装置获取该多个行故障地址，也可以是故障修复装置从本地获取该多个行故障地址，该其他装置可以是图2中的存储器202或bios芯片205。
74.s320、故障修复装置确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度。
75.上述行故障位置的故障严重程度越高，将导致系统发生不可纠正错误(uncorrected error，uce)的故障的概率越高，也就是说，行故障位置的故障严重程度是当前系统是否发生uce故障的决定性因素。
76.需要说明的是，上述确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度的方式包括：获取在预设时间段内内存中发生的第一行故障位置的故障次数，
和发生在第二行故障位置的故障次数。然后，将第一行故障位置的故障次数输入至评估模型，得到第一行故障位置的评分；将第二行故障地址的故障次数输入至评估模型，得到第二行故障地址的评分。其中，上述第一行故障位置的评分用于表征第一行故障位置的故障严重程度；上述第二行故障位置的评分用于表征第二行故障位置的故障严重程度。即：当行故障位置的评分(如：第一行故障位置的评分)与第一行故障位置的故障严重程度成正比时，第一行故障评分越高表示第一行故障位置的故障严重程度越高。当第一行故障评分与第一行故障位置的故障严重程度成反比是，第一行故障评分越高表示第一行故障位置的故障严重程度越低。
77.需要说明的是，上述行故障位置的故障次数(如：第一行故障位置的故障次数)用于表示上述预设时间段内内存中的第一行故障位置处(即同一故障行上)发生的行故障次数。
78.上述评估模型用于评估行故障位置的严重程度，其中，该评估模型是根据多组行故障位置的故障次数作为训练数据，训练得到的模型；其中，每组训练数据的标签为该训练数据对应的行故障位置的预设评分。
79.s330、故障修复装置依次对第一行故障位置和第二行故障位置进行修复。
80.上述行故障位置的故障严重程度越高，导致系统发生uce的故障的概率越高；所以上述故障严重程度越高的行故障位置越先被修复。
81.示例性的，假设第一行故障位置的故障严重程度高于第二行故障位置的故障严重程度时那么，故障修复装置先修复第一行故障位置后，再修第二行故障位置。
82.需要说明的是，上述对行故障位置进行修复的方式可以是ppr技术，也可以是其他修复行故障的技术，本技术实施例中以行故障位置的修复方式为ppr技术为例进行说明，后续不再赘述。
83.应理解的是，根据ppr技术对行故障位置进行修复的方式为：使用内存中冗余存储区域中的空闲行替换内存中存储区域中发生行故障的故障行，其中，该空闲行为冗余存储区域中没有被用于替换故障行的存储行(row)。
84.需要说明的是，上述冗余存储区域中的空闲行是有限的，当该空闲行的数量大于或等于上述多个行故障位置(如：第一行故障位置和第二行故障位置)对应的故障行的数量时；将按照该多个行故障位置的故障严重程度依次对该多个行故障位置全部进行修复。当该空闲行的数量小于上述多个行故障位置对应的故障行的数量时，将按照该多个行故障位置的故障严重程度依次对该多个行故障位置的部分行故障位置进行修复，其中，该部分行故障位置的数量与该空闲行的数量相等。
85.示例性的，如图5所示，假设冗余存储区域中的空闲冗余行(简称：空闲行)为冗余行1-4；内存的存储区域中的故障行位置有6个，分别为故障行1-6；那么；故障修复装置根据故障行1-6的故障严重程度，依次对该6个故障行中故障严重程度排前4的故障行进行替换。
86.应理解的是，由于ppr技术是在服务器重启阶段执行的修复动作，所以上述s330的执行时机为服务器发生重启的时机。
87.相比传统的按照多个行故障的发生时间依次对该多个行故障位置进行修复的方式，其中，发生时间越靠前的行故障位置，越先被修复；本技术实施例提供的故障修复方法是按照第一行故障位置和第二行故障位置的故障严重程度对该第一行故障位置和第二行
故障位置进行修复的，其中，故障严重程度越高的行故障位置被优先进行修复；从而避免了因内存中严重程度较高的行故障位置被晚修复或不被修复，从导致的系统出现宕机的情况；因此提高了内存的可靠性。
88.本技术实施例提供的另一种故障修复方法，如图6所示，该方法可以包括s610-s630。
89.s610、故障修复装置获取内存的第一行故障地址和第二行故障地址。
90.需要说明的是，上述s610的实现方式与s310的实现方式类似，具体对于s610的具体描述可以参考上述对于s310的相关描述，此处不再赘述。
91.s620、故障修复装置基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表。
92.上述目标故障列表中包括第一行故障位置和第二行故障位置，在该目标故障列表中的行故障位置是按照行故障位置的故障严重程度的大小进行排序的；也就是说，该目标故障列表中的行故障位置可以是按照行故障位置的故障严重程度由大到小的顺序进行排序的，也可以是按照行故障位置的故障严重程度由小到大的顺序进行排序的。
93.示例性的，假设上述目标故障列表中包括：行故障位置1、行故障位置2、行故障位置3以及行故障位置4；其中，该行故障位置1-4按照故障严重程度由大到小排序为：行故障位置3、行故障位置1、行故障位置4、行故障位置2；那么当目标故障列表中的行故障位置是按照故障严重程度由大到小进行排序时；该目标列表为{行故障位置3、行故障位置1、行故障位置4、行故障位置2}；当目标故障列表中的行故障地址是按照故障严重程度由小到大进行排序时；该目标列表为{行故障位置2、行故障位置4、行故障位置1、行故障位置3}。
94.上述第一行故障位置和第二行故障位置的故障严重程度的确定方式，与上述s320中确定行故障位置的故障严重程度的方式一致，此处不再赘述。
95.需要说明的是，上述s620可以是在服务器运行阶段时执行的，也可以是在该服务器重启阶段执行的；当s620在服务器运行阶段时执行时，在服务器重启阶段只需要根据目标故障列表中的行故障位置排序依次对目标故障列表中的行故障位置进行修复，并不需要对该多个行故障位置根据故障严重程度进行排序，因此，提高了服务器的重启效率。
96.应理解的是，当s620在服务器运行阶段执行时，上述s610一定是在服务器运行阶段执行的。当s620在服务器重启阶段执行时，上述s610可以是在服务器运行阶段执行，也可以是在服务器重启阶段执行。
97.需要说明的是，上述行故障位置的故障严重程度可以是在获取一个行故障位置后就确定该行故障位置的故障严重程度，也可以是在s620确定目标故障列表时确定每一个行故障位置的故障严重程度，具体本技术实施例不对确定行故障位置的故障严重程度的确定时机进行限定。
98.s630、故障修复装置按照目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复。
99.上述s630的具体实现方式是按照目标故障列表中的行故障位置的排序，对目标故障列表中的行故障位置按照故障严重程度由大到小的顺序依次进行修复。
100.示例性的，假设目标故障列表为：行故障3、行故障1、行故障4、行故障2；当目标故障列表中的行故障位置是按照故障严重程度由大到小的进行排序时，故障修复装置按照目
标故障列表中行故障位置的顺序依次进行修复。当目标故障列表中的行故障是按照故障严重程度由小到大进行排序时，故障修复装置按照目标故障列表中行故障位置的逆向顺序依次进行修复，如按照：行故障2、行故障4行故障1、行故障3的顺序进行修复。
101.需要说明的是，上述s630中对行故障位置进行修复的实现方式与s330中对行故障位置进行修复的实现方式类似，具体对于s630中对行故障位置进行修复的具体描述可以参考上述对于s330的相关描述，此处不再赘述。
102.应理解的是，由于ppr技术是在服务器重启阶段执行的修复动作，所以上述s630的执行时机为服务器发生重启的时机。
103.可选的，当执行上述s630的故障修复装置为图2中的bios芯片205时；上述s610-s620的执行主体可以是除故障修复装置以外的其他装置，如图2中的bmc芯片206；此时，bios芯片205与bmc芯片206交互过程如图7所示。
104.需要说明的是，上述图7中的s710-s740与上述s610-s630完全一致，此处不再赘述。
105.本技术实施例提供的故障修复方法，通过将第一行故障位置和第二行故障位置按照故障严重程度大小进行排序后得到目标故障列表；然后，在执行修复动作时，只需要根据目标故障列表中的行故障位置的排序，对该目标故障列表中的行故障位置按照故障严重程度由大到小的顺序依次进行修复，并不需要将每个行故障位置的故障严重程度与其他行故障位置的故障严重程度进行对比，因此，提高了行故障的修复效率。
106.可选的，结合图6，如图8所示，在上述s620确定目标故障列表之后，再次接收到行故障位置(第三行故障位置)时，本技术实施例提供的故障修复方法还包括：s621。
107.s621、故障修复装置根据第三行故障位置更新目标故障列表，得到更新后的目标故障列表。
108.上述第三行故障为预设时间段内发生的行故障，且第三行故障的发生时间在第一行故障和第二行故障的发生时间之后；该预设时间段为是从内存所在的服务器上一次重启的时间开始至该服务器本次重启的时间结束的时间段。上述第三行故障的发生时间与目标故障列表中的行故障的发生时间属于同一个预设时间段。
109.上述更新后的目标故障列表中的行故障位置是按照行故障位置的故障严重程度大小进行排序的。也就是说，故障修复装置接收到一个行故障位置后，根据该行故障位置的故障严重程度更新一次当前的故障目标列表。
110.该情况下，上述s630中的故障修复装置按照更新后的目标故障列表中的行故障位置的排序，依次对更新后的目标故障列表中的行故障位置进行修复。
111.需要说明的是，上述s621的具有实现过程如图9所示，包括两种情况，具体为s621a或(s621a-s621b)。
112.情况一：当第三行故障位置与第一行故障位置和第二行故障位置均不同时，包括:s621a。
113.s621a、故障修复装置将第三行故障位置添加进目标故障列表，得到更新后的目标故障列表。
114.需要说明的是，上述第三行故障位置与第一行故障位置和第二行故障位置均不同是指，第三行故障位置对应的故障行与上述第一行故障位置和第二行故障位置对应的多个
故障行不是同一个故障行；也就是说，第三行故障地址与第一行故障地址和第二行故障地址均不同。
115.上述更新后的目标故障列表中的行故障位置是按照故障严重程度大小进行排序的，也就是说，故障修复装置根据该第三行故障位置的故障严重程度，将该第三行故障位置障添加到目标故障列表的指定位置，进而得到更新后的目标故障列表。
116.应理解的是，当目标故障列表中的行故障位置是按照故障严重程度由大到小排序时，上述指定位置的前一个行故障位置的故障严重程度高于第三行故障位置的故障严重程度；该指定位置的后一个行故障位置的故障严重程度低于第三行故障位置的故障严重程度。当目标故障列表中的行故障是按照故障严重程度由小到大排序时，该指定位置的前一个行故障位置的故障严重程度低于第三行故障位置的故障严重程度；该指定位置的后一个行故障位置的故障严重程度高于第三行故障位置的故障严重程度。
117.示例性的，假设目标故障列表中的行故障位置是按照故障严重程度由小到大的进行排序的，该目标故障列表为：行故障3、行故障1、行故障4、行故障2。当行故障5(即：第三行故障位置)的故障严重程度低于行故障4的故障严重程度，且高于行故障1的故障严重程度时，将行故障5添加至目标故障列表中行故障1和行故障4的中间位置，即得到更新后的目标故障列表为行故障3、行故障1、行故障5、行故障4、行故障2。
118.情况二：当第三行故障位置与目标故障列表中的目标行故障位置相同时，包括：s621a-s621b。
119.s621a、故障修复装置更新目标行故障位置的故障次数，并根据更新后的目标行故障位置的故障次数重新计算目标行故障位置的故障严重程度。
120.上述目标行故障位置是目标故障列表中与第三行故障位置相同的行故障位置；也就是说，目标行故障位置和第三行故障位置是同一故障行上的故障。所以并不需要将第三行故障位置添加进行目标故障列表，只需对该目标故障列表中的故障次数进行更新；并根据更新后的目标行故障位置的故障次数重新计算目标行故障位置的故障严重程度。
121.需要说明的是，上述计算目标行故障位置的故障严重程度的方式与上述s320中确定第一行故障位置和第二行故障位置的故障严重程度的实现方式类似，具体对于s621a中确定目标行故障位置的故障严重程度的具体描述可以参考上述对于s320的相关描述，此处不再赘述。
122.s621b、故障修复装根据目标行故障位置的故障严重程度和非目标行故障位置的故障严重程度，更新目标故障列表，得到更新后的目标故障列表。
123.上述非目标行故障位置为上述目标故障列表中除目标行故障位置以外的行故障位置。
124.需要说明的是，上述更新后的目标故障列表中的行故障位置是按照故障严重程度大小进行排序的，也就是说，故障修复装置根据该更新数量后的目标行故障位置的故障严重程度，对目标故障列表中的行故障位置按照故障严重程度重新排序。
125.应注意的是，当故障修复装置执行完上述s621后，故障修复装置执行的s630为：根据ppr技术，并按照更新后的目标故障列表中的行故障位置的排序，依次对更新后的目标故障列表中的行故障位置进行修复。
126.相应地，本技术实施例提供一种故障修复装置，该故障修复装置用于执行上述故
障修复方法中的各个步骤，本技术实施例可以根据上述方法示例对该故障修复装置进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本技术实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
127.在采用对应各个功能划分各个功能模块的情况下，图10示出上述实施例中所涉及的故障修复装置的一种可能的结构示意图。如图10所示，该故障修复装置包括：获取模块1001、确定模块1002和修复模块1003。
128.获取模块1001用于获取内存的第一行故障地址和第二行故障地址，例如执行上述方法实施例中的步骤s310。
129.确定模块1002用于确定第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，例如执行上述方法实施例中的步骤s320。
130.修复模块1003用于依次对第一行故障位置和第二行故障位置进行修复，例如执行上述方法实施例中的步骤s330。
131.可选的，上述获取模块1001用于获取在预设时间段内发生在第一行故障位置的故障次数，和发生在第二行故障位置的故障次数。
132.上述确定模块1002用于将第一行故障位置的故障次数输入至评估模型，得到第一行故障位置的评分。
133.上述确定模块1002还用于将第二行故障地址的故障次数输入至评估模型，得到第二行故障地址的评分。
134.可选的，上述确定模块1002用于基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表，例如执行上述方法实施例中的步骤s620。
135.上述修复模块1003用于按照目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复，例如执行上述方法实施例中的步骤s630。
136.可选的，上述确定模块1002用于当服务器在运行阶段时，基于第一行故障位置的故障严重程度和第二行故障位置的故障严重程度，确定目标故障列表。
137.上述修复模块1003用于当服务器在重启阶段时，按照目标故障列表中的行故障位置的排序，依次对目标故障列表中的行故障位置进行修复。
138.可选的，上述故障修复装置还包括：更新模块1004。
139.上述更新模块1004用于根据第三行故障位置更新目标故障列表，得到更新后的目标故障列表，例如执行上述方法实施例中的步骤s621。
140.上述修复模块1003用于按照更新后的目标故障列表中的行故障位置的排序，依次对更新后的目标故障列表中的行故障位置进行修复。
141.可选的，上述更新模块1004用于当第三行故障位置与第一行故障位置和第二行故障位置均不同时，将第三行故障位置添加进目标故障列表，得到更新后的目标故障列表，例如执行上述方法实施例中的步骤s621a。
142.上述更新模块1004用于当第三行故障位置与第一行故障位置和第二行故障位置相同时，更新目标行故障位置的故障次数，并根据更新后的目标行故障位置的故障次数重新计算目标行故障位置的故障严重程度，例如执行上述方法实施例中的步骤s621a。
143.上述更新模块1004还用于根据目标行故障位置的故障严重程度和非目标行故障位置的故障严重程度，更新目标故障列表，得到更新后的目标故障列表，例如执行上述方法实施例中的步骤s621b。
144.上述故障修复装置的各个模块还可以用于执行上述方法实施例中的其他动作，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
145.其中，获取模块1001、确定模块1002,、修复模块1003和更新模块1004中的部分或全部步骤可以通过图1中的处理器101执行内存103中的代码实现。
146.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机指令时，全部或部分地产生按照本技术实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))方式或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、磁盘、磁带)、光介质(例如，数字视频光盘(digital video disc，dvd))、或者半导体介质(例如固态硬盘(solid state drives，ssd))等。
147.通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
148.在本技术所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
149.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
150.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
151.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
152.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。