关于服务器:服务器内存故障预测居然可以这样做

3次阅读

共计 6500 个字符，预计需要花费 17 分钟才能阅读完成。

作者：vivo 互联网服务器团队 - Hao Chan

随着互联网业务的疾速倒退，基础设施的可用性也越来越受到业界的关注。内存产生故障的故障率高、频次多、影响大，这些对于下层业务而言都是不能承受的。

本文次要介绍 EDAC（Error Detection And Correction）框架在内存预测方面的利用。首先介绍了 EDAC 利用的背景，接着是 EDAC 的原理介绍，而后通过 EDAC 装置——配置——测试过程具体地介绍了 EDAC 在 vivo 服务器上的利用，最初提出了内存预测应用 EDAC 的计划总结以及服务器 RAS（Reliability, Availability and Serviceability）利用减小硬件故障对系统的影响的瞻望。

随着互联网业务的疾速倒退，基础设施的可用性也越来越受到业界的关注。然而硬件故障始终以来都是一种普遍存在的景象，因为硬件故障而造成的损失往往是微小的。在服务器各个部件中，除硬盘故障以外，内存故障是第二大常见的硬件故障类型。并且服务器内存的数量泛滥，vivo 的内存数量达到 40w+ 条，内存故障造成的最重大的结果是会间接导致系统解体，服务器宕机，这些对于下层业务而言都是不能承受的。

内存故障可分为 UCE（Uncorrectable Error）和 CE（Correctable Error）。当硬件侦测到一个谬误，它会通过两种形式报告给 CPU 的。其中一种形式是中断，这种状况如果是 UCE 也就是不可纠正错误，则可能会导致服务器立马宕机。如果是 CE，即可纠正错误，硬件会利用一部分资源对该谬误进行修复，而当内存 CE 累计过多，无奈进行自我修复时，则会产生 UCE，造成零碎宕机重启。因而，咱们须要尽早地发现 CE 过多的内存条，及时进行更换，防止造成重大的损失。

以往内存故障大多是通过 MCE（Machine Check Exception）log 和 BMC 记录的 SEL（System Error Log）日志联合去发现定位故障的，而这些最大的问题是不可能提前发现内存问题，往往是服务器宕机重启后才被动发现的。除此之外还存在以下几个方面的问题：

MCE 日志很难间接定位到故障内存槽位。

没有直观的 CE/UCE 谬误计数。

无奈依据内存条上 CE/UCE 的数量判断内存的健康状况。

针对以上问题，咱们须要寻找别的解决方案。这时 EDAC 便呈现在咱们的视线，它可能完满地解决下面所说的所有问题，并且可能实现内存 CE 故障的被动发现，提前发现内存问题。

本文将次要介绍 EDAC 的原理以及如何通过它实现的故障预测。

EDAC（Error Detection And Correction）是 Linux 零碎的谬误检测和纠正的框架，它的目标是在 linux 零碎运行过程中，当谬误产生时可能发现并且报告出硬件谬误。EDAC 由一个外围（edac\_core.ko）和多个内存控制器驱动模块组成，它的子系统有 edac\_mc、edac_device、PCI bus scanning，别离是负责收集内存控制器，其余控制器（比方 L3 Cache 控制器）以及 PCI 设施所报告的谬误。

这里次要讲述 EDAC 子系统 edac\_mc 是如何收集内存控制器的谬误。内存 CE 以及 UCE 是 edac\_mc class 获取的次要谬误类型，它次要波及了以下几个函数：

【edac\_mc\_alloc()】：应用构造体 mem\_ctl\_info 来形容内存控制器，只有 EDAC 的外围能力接触到它，通过 edac\_mc\_alloc()这个函数去调配填充构造体的内容。

【edac\_device\_handle_ce()】：标记 CE 谬误。

【edac\_device\_handle_ue()】：标记 UCE 谬误。

【edac\_mc\_handle_error()】：向用户空间报告内存事件，它的参数包含故障点的层次结构以及故障类型，累计的相干 UCE/CE 谬误计数统计。

【edac\_raw\_mc\_handle\_error()】：向用户空间报告内存事件，然而不做任何事件来发现它的地位，只有当硬件谬误来自 BIOS 时，才会被 edac\_mc\_handle_error()间接调用。

那么 EDAC 是如何管制和报告设施故障的呢？它又是如何将故障定位以及记录到对应的内存条上的呢？

Linux 是通过 sysfs 文件系统来展现内核设施的档次关系，EDAC 则通过它来管制和报告设施故障。EDAC 是通过形象进去的内存控制器模型，将故障定位到对应的内存条上，这次要也是与内存在零碎中的排列构造相干。CPU 对应的每个 MC（memory controller）设施管制着一组 DIMM 内存模块，这些模块通以片选行 (Chip-Select Row,csrowX) 和通道 (Channel,chX) 的形式排布，在零碎中能够有多个 csrow 和多个通道。

通过下列门路能够查看相干文件：

# ls /sys/devices/system/edac/mc/mc0/csrow0/
ce_count  ch0_ce_count  ch0_dimm_label  ch1_ce_count  ch1_dimm_label  dev_type  edac_mode  mem_type  power  size_mb  subsystem  ue_count  uevent

局部文件的用处如下表所示：

EDAC 如果发现硬件设施控制器报告的是 UE 事件，并且控制器要求 UE 即停机，则会重启零碎。控制器查看到 CE 事件后，能够看作对将来 UCE 事件的预测。咱们能够通过一些屏蔽伎俩或者更换内存条缩小 UE 事件以及零碎宕机的可能性。

EDAC 在 vivo 现网中的利用过程次要分为以下几步：

（1）EDAC 在 Linux 零碎中的反对

EDAC 在 Linux 2.6.16 以上的内核中以及零碎发行版都曾经失去了反对，然而内核中 edac 的驱动模块却有很多，不同的零碎版本反对的驱动模块却不尽相同，能够通过以下形式查看零碎反对哪些驱动模块。

# ls /lib/modules/3.10.0-693.el7.x86_64/kernel/drivers/edac/
amd64_edac_mod.ko.xz  edac_core.ko.xz     i3000_edac.ko.xz  i5000_edac.ko.xz  i5400_edac.ko.xz  i7core_edac.ko.xz   ie31200_edac.ko.xz  skx_edac.ko.xz
e752x_edac.ko.xz      edac_mce_amd.ko.xz  i3200_edac.ko.xz  i5100_edac.ko.xz  i7300_edac.ko.xz  i82975x_edac.ko.xz  sb_edac.ko.xz       x38_edac.ko.xz

那么这些驱动模块之间有什么区别？咱们又应该怎么抉择呢？拿 sb\_edac 与 skx\_edac 进行阐明，咱们先来看一下它们形容。

# modinfo sb_edac
filename:       /lib/modules/3.10.0-693.el7.x86_64/kernel/drivers/edac/sb_edac.ko.xz
description:    MC Driver for Intel Sandy Bridge and Ivy Bridge memory controllers -  Ver: 1.1.1
...

# modinfo skx_edac
filename:       /lib/modules/3.10.0-693.el7.x86_64/kernel/drivers/edac/skx_edac.ko.xz
description:    MC Driver for Intel Skylake server processors
...

通过查看形容咱们发现，原来驱动模块是和 CPU 的产品架构无关，装置不匹配的模块会呈现 edac-util: Error: No memory controller data found 这样的报错。通过咱们测试发现，一般而言，如果 CPU 的产品架构反对的驱动模块存在的话，零碎会默认装置反对的驱动。

（2）配置内存槽位与物理槽位对应关系

通过 sysfs 文件系统咱们能够看到哪个 CPU 的哪个内存管制下的哪个通道的哪条内存的 CE 计数，然而它对应的零碎下的哪一个内存呢，毕竟咱们服务器日常的运维，常常看到的是零碎槽位名称，那么它们的关系是怎么的呢？

通过查看 edac-util 的源代码构造发现，它提供了 labels.db 这个配置文件，去存储服务器内存的零碎槽位与物理槽位对应关系。

# cat /etc/edac/labels.db
# EDAC Motherboard DIMM labels Database file.
#
# $Id: labels.db 102 2008-09-25 15:52:07Z grondo $
#
#  Vendor-name and model-name are found from the program 'dmidecode'
#  labels are found from the silk screen on the motherboard.
#
#Vendor: <vendor-name>
#  Model: <model-name>
#    <label>:  <mc>.<row>.<channel>

编写这个文件的时候，咱们须要晓得内存是如何在服务器上是怎么插，并且晓得它对应的是零碎中的槽位名称，不同服务器型号零碎槽位的名称不同。个别能使内存性能施展最大的插法，总结起来就是对称插法，并且先插离 CPU 远的通道，每个通道外面先插离 CPU 远的槽位。

配置实现后，如何去查看是否配置正确呢，次要分为两步：

① 应用 edac-ctl 查看 SYSFS CONTETS 条数是否正确

② 用 dmidecode -t memory 查看内存的名称是否统一

这里咱们还遇到一个 rpm 包的问题：对于厂商的主板的 model name 前后有多个空格的状况，edac-ctl 无奈辨认到主板的 model name，lables.db 无奈注册胜利。最初咱们批改了 edac-utils 包的源代码，从新进行了打包。

（3）测试与验证

装置配置实现后，就到了测试验证环节了，要怎么去验证 EDAC 的正确性，保障 CE 谬误记录到了对应的内存条上呢？咱们能够应用 APEI Error inject 做一些谬误注入的测试。

APEI Error inject 它的原理是依赖 APEI（ACPI Platform Error Interface），它的构造中有四张表：

BERT（Boot Error Record Table）：次要用来记录在启动过程中呈现的谬误

ERST（Error Record Serialization Table) ：用来永恒存储谬误的形象接口，存储各种硬件或平台的相干谬误，谬误类型包含 Corrected Error（CE），Uncorrected Recoverable Error（UCR），以及 Uncorrected Non-Recoverable Error，或者说 Fatal Error。

EINJ（Error Injection Table）：次要作用是用来注入谬误并触发谬误，是一个用来测试的表

HEST（Hardware Error Source Table）：定义了很多谬误源和谬误类型。定义这些硬件谬误源的目标在于标准化软硬件谬误接口的实现。

这里是通过 debugfs 向内核 APEI 构造中的 EINJ 表注入内存谬误来进行测试，debugfs 是一种用于内核调试的虚构文件系统，简略来说就是能够通过 debugfs 映射内核数据到用户空间，使用户可能批改一些数据进行调试。

办法步骤如下：

# 查看是否存在 EINJ 表
# ls /sys/firmware/acpi/tables/EINJ 

# grep < 以下字段 > /boot/config-3.10.0-693.el7.x86_64

CONFIG_DEBUG_FS=y 
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_EINJ=m

# 装置 einj
# modprobe einj


# 查看内存地址范畴，这一步是因为 /proc/iomem 这个文件记录的是物理地址的分配情况，有些内存地址是零碎预留寄存以及其余设施所占用的，无奈进行谬误注入。# cat /proc/iomem | grep "System RAM"
00001000-000997ff
00100000-69f79fff
6c867000-6c9e6fff
6f345000-6f7fffff
100000000-407fffffff

# 查看内存页大小
# getconf PAGESIZE
4096 即 4KB

# 进入 edac 谬误注入目录

# cat /proc/mounts | grep debugfs
debugfs /sys/kernel/debug debugfs rw,relatime 0 0

# cd  /sys/kernel/debug/apei/einj/

# 查看反对注入的谬误类型
# cat available_error_type
0x00000008  Memory Correctable
0x00000010  Memory Uncorrectable non-fatal
0x00000020  Memory Uncorrectable fatal

# 写入要注入的谬误的类型
echo 0x8 > error_type 

# 写入内存地址掩码
echo 0xfffffffffffff000 > param2

# 写入内存地址
echo 0x32dec000 > param1

# 写入 0x0，若为 1，则会跳过触发环节
echo 0x0 > notrigger

# 写入任何整数触发谬误注入，这是谬误注入的最初一步
echo 1 > error_inject

# 查看日志
# tail /var/log/message
xxxxxx xxxxxxxx kernel: [2258720.203422] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_MC#0_Chan#0_DIMM#1 (channel:0 slot:1 page:0x32dec offset:0x0 grain:32 syndrome:0x0 -  err_code:0101:0090 socket:0 imc:0 rank:0 bg:0 ba:3 row:327 col:300)

# 应用 edac-util - v 查看，能够看到对应的内存条上新增了 CE 计数

EDAC 能够明确的获取到服务器的每条内存上的 CE 计数，咱们能够通过 CE 计数去设定阈值，剖析 CE 计数曲线等，联合其余 MCE log、SEL 等对内存进行健康状况评估，进行内存预测。EDAC 在 vivo 服务器全量上线过程以来，累计提前发现 450+ case 的内存 CE 问题，服务器的宕机数量显著缩小。对满足报修规范服务器业务进行迁徙，并更换相应的内存条，防止因服务器忽然宕机导致业务的不稳固，甚至因而造成的损失。
EDAC 是服务器 RAS（Reliability, Availability and Serviceability）在内存方面利用的一小部分。RAS 是指通过一些技术手段，软硬件联合去保障服务器的这三个能力。RAS 在内存方面的优化还有很多，例如 MCA（Machine Check Architecture）recovery 等等。将来咱们也将引入 RAS 去缓解硬件故障对系统的影响。

参考资料：

https://www.kernel.org/doc/html/latest/driver-api/edac.html
https://www.kernel.org/doc/html/latest/admin-guide/ras.html
https://www.kernel.org/doc/html/latest/firmware-guide/acpi/apei/einj.html
https://github.com/grondo/edac-utils/
https://uefi.org/specs/ACPI/6.4/18\_ACPI\_Platform\_Error\_Interfaces/ACPI\_PLatform\_Error_Interfaces.html

正文完