内存故障检测edac+MCA
重点都在intel EDS中
EDAC
https://www.kernel.org/doc/html/v4.14/driver-api/edac.html
x86架构—MCA
https://www.codenong.com/cs106476885/
【x86架构】MCA
https://blog.csdn.net/jiangwei0512/article/details/62456226
其他参考 https://blog.csdn.net/jiangwei0512/category_9286944.html
MCA介绍
https://zhuanlan.zhihu.com/p/685525889
MCA机制:硬件错误检测架构
https://blog.csdn.net/chengm8/article/details/53003134
RAS(二)Intel MCA初探
https://cloud.tencent.com/developer/article/2314691
RAS(四)Intel MCA-Uncorrected Recoverable
https://cloud.tencent.com/developer/article/2314691
Machine-check架构 Intel® 64 and IA-32 Architectures Software Developer Manuals的第15、16章
https://huataihuang.gitbooks.io/cloud-atlas/content/os/linux/kernel/cpu/analysis_cpu_mce.html
RAS---->MCA–>Overview TIP: 名词解释: MCA:Machine Check Architecture MSR:Model Specific Register MCE:Machine Check Error #MC:Machine Check Exception CMCI:Corrected Machine Check Error Interrupt 一 前情提要: RAS可以粗暴的理解为要实现的目的。 实现这个目的的方法之一就是采用(MCA)机制,而这个机制需要通过一定数量的MSR(寄存器)来实现。这两个寄存器分成两部分,一部分用来进行设置,一部分描述硬件错误。 ERROR: CPU检测MCE时,会对error进行处理。 Error分两种,可纠正的MCE和不可纠正的MCE。处理方法有所不同。 不可纠正的MCE:触发#MC,通常软件会注册相关的函数来处理#MC,在这个函数中会通过读取MSR来收集MCE的错误信息,然后重启系统。当然由于发生的MCE可能是非常致命的,CPU直接重启了,没有办法完成MCE处理函数;甚至有可能在MCE处理函数中又触发了不可纠正的MCE,也会导致系统直接重启。 可纠正的MCE:当可纠正的MCE数量超过一定的阈值时,会触发CMCI(Corrected Machine Check Error Interrupt),此时软件可以捕捉到该中断并进行相应的处理。CMCI是在MCA之后才加入的,算是对MCA的一个增强,在此之前软件只能通过轮询可纠正MCE相关的MSR才能实现相关的操作。 至此,总算是理清MCA MSR MCE CMCI 之间的关系了
linux下提供的MCA SYS 接口
https://blog.csdn.net/melody9040/article/details/129261637
The new handler can be configured at system run time by reading or writing the control files in /sys/devices/system/machinecheck/machinecheck0/ 10 Val are: • tolerant Tolerance level. The higher this level the more risk the machine check handler takes to keep the machine running. Valid levels are: 0 always panic on uncorrected errors. 1 panic if deadlock possible 2 try to avoid panic at slight deadlock risk 3 never panic or exit (for testing only) Specifying oops=panic on the kernel command line implies zero tolerance. For a cluster setting tolerant to zero may be best, together with panic=10 to force an reboot. • check interval Interval in seconds to check for silent machine check events. Default 5 minutes. 0 disables background checking. • bank0ctl … bankNctl Binary mask of errors enabled in bank N. Default is to enable all errors in each bank. An disabled error will be ignored. For details on the banks and their sub-errors for AMD and Intel CPUs see [opteron] https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git v198 https://git.kernel.org/pub/scm/utils/cpu/mce/mcelog.git/snapshot/mcelog-198.tar.gz
使用edac工具来检测服务器内存故障. mc06 表示 表示内存控制器0; CPU_Src_ID#0 表示源CPU0; Channel#0 表示通道0; DIMM#0 标示内存槽0; Corrected Errors 代表已经纠错的次数; 根据前面列出的CPU通道和内存槽对应关系即可给edac-utils 返回的信息进行编号。 即可得出 A1槽 6312 次纠错,B1槽 6459次纠错,B3槽 535次纠错. 3条内存出现潜在故障,接下来联系供应商进行更换即可。 随着虚拟化,Redis,BDB内存数据库等应用的普及,现在越来越多的服务器配置了大容量内存,拿DELL的R620来说在配置双路CPU下,其24个内存插槽,支持的内存高达960GB。对于ECC,REG这些带有纠错功能的内存故障检测是一件很头疼的事情,出现故障,还是可以连续运行几个月甚至几年,但如果运气不好,随时都会挂掉,好在linux中提供了一个edac-utils 内存纠错诊断工具,可以用来检查服务器内存潜在的故障。 下面以CentOS为例,介绍下edac-utils 工具的使用. 在使用edac-utils 工具之前,需要先了解服务器的硬件架构,以DELL R620为例,(其它如HP DL360P G8,IBM X3650 M4 机型都使用了 E5-2600 系列CPU,C600 系列芯片组.大致相同) 其CPU内存控制器对应通道,内存槽关系,如下所示。 处理器0 (对应一个内存控制器) 通道0:内存插槽A1、A5 和A9 通道1:内存插槽A2、A6 和A10 通道2:内存插槽A3、A7 和A11 通道3:内存插槽A4、A8 和A12 处理器1 (对应一个内存控制器) 通道0:内存插槽B1、B5 和B9 通道1:内存插槽B2、B6 和B10 通道2:内存插槽B3、B7 和B11 通道3:内存插槽B4、B8 和B12 1.安装 edac-utils 工具 yum install -y libsysfs edac-utils 2.执行检测命令,可查看纠错提示如下 edac-util -v mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#0_DIMM#0: A1 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#1_DIMM#0: A2 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#2_DIMM#0: A3 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#3_DIMM#0: A4 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#0_DIMM#1: A5 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#1_DIMM#1: A6 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#2_DIMM#1: A7 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#3_DIMM#1: A8 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#0_DIMM#2: A9 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#1_DIMM#2: A10 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#2_DIMM#2: A11 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#3_DIMM#2: A12 mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#0_DIMM#0: B1 mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#1_DIMM#0: B2 mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#2_DIMM#0: B3 mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#3_DIMM#0: B4 mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#0_DIMM#1: B5 mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#1_DIMM#1: B6 mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#2_DIMM#1: B7 mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#3_DIMM#1: B8 mc1: csrow2: CPU_SrcID#1_Ha#0_Chan#0_DIMM#1: B9 mc1: csrow2: CPU_SrcID#1_Ha#0_Chan#1_DIMM#1: B10 mc1: csrow2: CPU_SrcID#1_Ha#0_Chan#2_DIMM#1: B11 mc1: csrow2: CPU_SrcID#1_Ha#0_Chan#3_DIMM#1: B12 其中 mc0 表示 表示内存控制器0, CPU_Src_ID#0表示源CPU0 , Channel#0 表示通道0 DIMM#0 标示内存槽0,Corrected Errors 代表已经纠错的次数,根据前面列出的CPU通 道和内存槽对应关系即可给edac-utils 返回的信息进行编号。 即可得出 A1槽 6312 次纠错,B1槽 6459次纠错,B3槽 535次纠错. 3条内存出现潜在故障,接下来联系供应商进行更换即可。 12条内存的对应关系 mc0: csrow0: CPU#0Channel#0_DIMM#0: A1 mc0: csrow0: CPU#0Channel#1_DIMM#0: A2 mc0: csrow0: CPU#0Channel#2_DIMM#0: A3 mc0: csrow1: CPU#0Channel#0_DIMM#1: A4 mc0: csrow1: CPU#0Channel#1_DIMM#1: A5 mc0: csrow1: CPU#0Channel#2_DIMM#1: A6 mc1: csrow0: CPU#1Channel#0_DIMM#0: B1 mc1: csrow0: CPU#1Channel#1_DIMM#0: B2 mc1: csrow0: CPU#1Channel#2_DIMM#0: B3 mc1: csrow1: CPU#1Channel#0_DIMM#1: B4 mc1: csrow1: CPU#1Channel#1_DIMM#1: B5 mc1: csrow1: CPU#1Channel#2_DIMM#1: B6 20条内存的对应关系 mc0: 0 Uncorrected Errors with no DIMM info mc0: 0 Corrected Errors with no DIMM info mc0: csrow0: 0 Uncorrected Errors mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#0_DIMM#0: 0 Corrected Errors A1 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#1_DIMM#0: 0 Corrected Errors B1 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#2_DIMM#0: 0 Corrected Errors C1 mc0: csrow0: CPU_SrcID#0_Ha#0_Chan#3_DIMM#0: 0 Corrected Errors D1 mc0: csrow1: 0 Uncorrected Errors mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#0_DIMM#1: 0 Corrected Errors A2 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#1_DIMM#1: 0 Corrected Errors B2 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#2_DIMM#1: 0 Corrected Errors C2 mc0: csrow1: CPU_SrcID#0_Ha#0_Chan#3_DIMM#1: 0 Corrected Errors D2 mc0: csrow2: 0 Uncorrected Errors mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#0_DIMM#2: 0 Corrected Errors A3 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#1_DIMM#2: 11 Corrected Errors B3 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#2_DIMM#2: 0 Corrected Errors C3 mc0: csrow2: CPU_SrcID#0_Ha#0_Chan#3_DIMM#2: 0 Corrected Errors D3 mc1: 0 Uncorrected Errors with no DIMM info mc1: 0 Corrected Errors with no DIMM info mc1: csrow0: 0 Uncorrected Errors mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#0_DIMM#0: 0 Corrected Errors mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#1_DIMM#0: 0 Corrected Errors mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#2_DIMM#0: 0 Corrected Errors mc1: csrow0: CPU_SrcID#1_Ha#0_Chan#3_DIMM#0: 0 Corrected Errors mc1: csrow1: 0 Uncorrected Errors mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#0_DIMM#1: 0 Corrected Errors mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#1_DIMM#1: 0 Corrected Errors mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#2_DIMM#1: 0 Corrected Errors mc1: csrow1: CPU_SrcID#1_Ha#0_Chan#3_DIMM#1: 0 Corrected Errors 4x16关系 mc0: csrow0: CPU#0Channel#0_DIMM#0: 0 Corrected Errors 8a mc0: csrow0: CPU#0Channel#1_DIMM#0: 0 Corrected Errors 5b mc0: csrow0: CPU#0Channel#2_DIMM#0: 0 Corrected Errors 2c mc0: csrow1: 0 Uncorrected Errors mc0: csrow1: CPU#0Channel#0_DIMM#1: 1 Corrected Errors 7d mc0: csrow1: CPU#0Channel#1_DIMM#1: 0 Corrected Errors 4e mc0: csrow1: CPU#0Channel#2_DIMM#1: 0 Corrected Errors 1f mc0: csrow2: 0 Uncorrected Errors mc0: csrow2: CPU#0Channel#0_DIMM#2: 0 Corrected Errors 6G mc0: csrow2: CPU#0Channel#1_DIMM#2: 0 Corrected Errors 3h
=============
https://www.cnblogs.com/vivotech/p/16516881.html
服务器内存故障预测居然可以这样做!
作者: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 原理介绍
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 的应用
EDAC在vivo 现网中的应用过程主要分为以下几步: (1)EDAC在Linux系统中的支持 EDAC在Linux 2.6.16以上的内核中以及系统发行版都已经得到了支持, 但是内核中edac的驱动模块却有很多,不同的系统版本支持的驱动模块却不尽相同,可以通过以下方式查看系统支持哪些驱动模块。 ```sh # 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
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 全网最简单!3分钟用满血DeepSeek R1开发一款AI智能客服,零代码轻松接入微信、公众号、小程
· .NET 10 首个预览版发布,跨平台开发与性能全面提升