一种确定内存故障修复方式的方法、装置及存储介质与流程

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


背景技术：

2.随着互联网技术的广泛应用，内存的可靠性已成为各大企业关注的重点。经数据统计发现，内存中的行(row)故障是降低内存可靠性和引发服务器宕机的因素之一；传统的处理行故障的方式为基于行替换(post-package repair，ppr)的方式。
3.众所周知，上述ppr的方式是将内存分为冗余存储区域和存储区域；其中，存储区域用于存储数据，冗余存储区域用于替换存储区域中发生故障的区域。该ppr的方式包括：软件行替换(soft post-package repair，sppr)的方式和硬件行替换(hardware post-package repair，hppr)；其中，sppr的方式是在预定时间内使用冗余存储区域中的空闲存储区域替换发生故障的区域；该预定时间包括从内存所在的服务器发生重启时触发sppr的方式开始直至该服务器下次发生重启时结束。hppr的方式是使用冗余存储区域中的空闲存储区域永久性的替换发生故障的区域，其中，hppr和sppr的方式触发时机均为发生故障后内存所在的服务器执行的第一次重启动作的时间。
4.传统的基于ppr处理行故障的具体过程包括：单板管理控制器(baseboard management controller，bmc)接收到第一行故障信息时，记录该第一行故障的地址；当接收到第二行故障信息时，记录第二行故障的地址，并删除之前记录的第一行故障的地址。以此往复，直至bmc所在的服务器发生重启时，bmc根据预设的sppr或hppr修复bmc在该服务器发生重启前，最后一次记录的行故障。
5.上述bmc是根据预设的sppr或hppr处理目标行故障，将导致冗余存储区域中的存储资源的浪费和内存可靠性降低。


技术实现要素：

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