一、诡异服务器电源故障造成Redis慢查询
1、系统询发现问题：
我们和业务排查问题时候发现:
每天时不时发生：一些小的和硬get命令，耗时达到了40ms（正常是障导微秒级别）。慢查询集中在1台服务器的慢查全部实例。实例
角色
耗时(微秒)
命令
value大小
10.xx.xx.xx:yy
master
41,诡异432
get rta_12345xxxx
15字节
10.xx.xx.xx:yy
master
41,613
get rta_6789yyyyy
15字节
2、定位问题：
(1) 快速定位：快速定位为服务器问题，系统询因为同机器的和硬其他Redis集群均出现上述情况。
机器问题几板斧：
分钟级核心指标：cpu、障导mem、慢查网络、诡异io一通查，系统询没有异常。和硬系统日志：dmesg日志一通查，障导没有异常。慢查硬件问题：内存、网卡、CPU均正常，只有一台电源异常（当前是单路供电）(2) 深入定位因为之前定位过类似问题，单路供电能会导致CPU降频，但是查询监控未发现有降频：
图片
中间又辗转怀疑了很多点，最后排查同学还是怀疑和电源故障有关。
添加了CPU主频秒级监控：发现一瞬间降频（从2800MHz 降低到了 120 MHz）时间点和Redis慢查询时间点一致。
图片
3、服务器托管后续优化：
监控单服务器慢查询数量：基本上有多个集群都有慢查询，机器可能就有问题。对于单路电源故障，之前绝对非高优维修，后期需要对此磊故障增加优先级。添加对CPU频率告警和提供秒级诊断工具能力。二、服务器MCE造成Redis慢查询
1、发现问题：
某周末晚上，某业务在21:55可用性突然报警，从100%->98%，经排查该分钟该集群的全部实例出现慢日志(均为小命令)，并且集中在一台机器。
实例
角色
耗时(微秒)
命令
value大小
10.xx.xx.xx:yy
master
20,421
incr small_key1
10字节
10.xx.xx.xx:yy
master
21,324
get small_key2
10字节
图片
2、定位问题：
(1) 快速定位：快速定位为服务器问题，因为同机器的其他Redis集群均出现上述情况。
机器问题几板斧：
分钟级核心指标：cpu、mem、网络、io一通查，没有异常。硬件问题：内存、网卡、CPU、电源均正常。系统日志：dmesg有异常日志，初步判断MCE在做内存故障纠错。 复制May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 4 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: It has been corrected by h/w and requires no further action May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: event severity: corrected May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: Error 0, type: corrected May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: fru_text: A2 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: section_type: memory error May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: error_status: 0x0000000000000400 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: physical_address: 0x00000009f7466ac0 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: node: 0 card: 1 module: 0 rank: 0 bank: 0 row: 18297 column: 936 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: error_type: 2, single-bit ECC May 18 21:55:04 机器名 kernel: core: [Hardware Error]: Machine check events logged May 18 21:55:04 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7466 offset:0xac0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:04 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7467 offset:0x5c0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:04 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7441 offset:0xa40 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:04 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7447 offset:0x140 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:05 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7443 offset:0x640 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:05 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7444 offset:0x240 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:06 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f74e5 offset:0x3c0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:06 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7461 offset:0xac0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:06 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7460 offset:0x3c0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:06 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7464 offset:0x2c0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0) May 18 21:55:07 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7440 offset:0x340 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0)1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22. (2) 一些基础知识(我也是临时学的，如果不对欢迎来喷)什么是IT技术网MCE？MCE全称Machine check exception，英文解释如下(论文：https://www.halobates.de/mce.pdf)，简单说有硬件错误，需要中断当前的进程，调用一个专用的硬件异常处理handler进行处理。
复制A machine check exception happens when there is an error that the hardware cannot correct. It will cause the CPU to interrupt the current program and call a special exception handler. With a silent machine check the hardware was abl1.2. MCE什么时候触发通过修改/sys/devices/system/machinecheck/machinecheck0/check_interval 的值，可以调整错误修复的初始和最大轮询间隔。
硬件错误分类CE，可纠正错误；（注意这里的CE和MCE也不是一个东西，corrected exception）UE，不可纠正错误，但系统没有崩溃（通常进程coredump，异常退出）；Fatal，不可纠正错误，系统崩溃。从可用性角度看，似乎最应该关注的是2，3类错误，但实际上1类错误更具有欺骗性，在分布式系统中，确定性要好过不确定性。
x86处理硬件故障的方式PCIe AER 是PCIe的新特性，亿华云发生故障时，通过中断报告故障详情；APEI，先通过SMI进入BIOS/firmware，让BIOS/firmware先处理，其根据处理情况决定要不要通知OS继续处理；BIOS/firmware 可以通过MCE中断，让OS继续处理。这里重点是SMI中断（SMI中断使CPU进入SMM），它是Linux无法感知的，如果BIOS/firmware 处理错误耗费了太长时间，可能导致延迟抖动，没有统一的方法从Linux测度量。而其它中断是Linux处理的，其耗时Linux总是有办法度量。
(3) 日志分析，几个核心点：CE Memory：可纠正的内存错误 复制May 18 21:55:04 机器名 kernel: EDAC MC0: 0 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0x9f7466 offset:0xac0 grain:32 syndrome:0x0 - area:DRAM err_code:0000:009f socket:0 ha:0 channel_mask:2 rank:0)1. 关键日志： 复制Machine check events logged1. 内存错误和内存信息： 复制May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: fru_text: A2 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: section_type: memory error May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: error_status: 0x0000000000000400 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: physical_address: 0x00000009f7466ac0 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: node: 0 card: 1 module: 0 rank: 0 bank: 0 row: 18297 column: 936 May 18 21:55:04 机器名 kernel: {2}[Hardware Error]: error_type: 2, single-bit ECC1.2.3.4.5.6.3、结论：
系统发生硬件错误会导致机器进入 MCE中断，可能会将大部份内核时间用于处理 MCE中断(例如本例子CE Memory)。
三、THP造成
这个就是一个凑数的，很早之前遇到的，在《Redis开发与运维》一书也提过，原文如下：
图片
四、其他案例
1、不可纠正硬件错误：
Uncorrected hardware memory error ，导致Redis直接core。
复制May 27 15:48:58 机器名 kernel: core: Uncorrected hardware memory error in user-access at 1a1f914a80 May 27 15:48:58 机器名 kernel: core: [Hardware Error]: Machine check events logged May 27 15:48:58 机器名 mcelog: Hardware event. This is not a software error. May 27 15:48:58 机器名 mcelog: MCE 0 May 27 15:48:58 机器名 mcelog: CPU 15 BANK 1 TSC e7a1f64e03e47a May 27 15:48:58 机器名 mcelog: RIP 33:465af1 May 27 15:48:58 机器名 mcelog: MISC 86 ADDR 1a1f914a80 May 27 15:48:58 机器名 mcelog: TIME 1716796138 Mon May 27 15:48:58 2024 May 27 15:48:58 机器名 mcelog: MCG status:RIPV EIPV MCIP LMCE May 27 15:48:58 机器名 mcelog: MCi status: May 27 15:48:58 机器名 mcelog: Uncorrected error May 27 15:48:58 机器名 mcelog: Error enabled May 27 15:48:58 机器名 mcelog: MCi_MISC register valid May 27 15:48:58 机器名 mcelog: MCi_ADDR register valid May 27 15:48:58 机器名 mcelog: SRAR May 27 15:48:58 机器名 mcelog: MCA: Data CACHE Level-0 Data-Read Error May 27 15:48:58 机器名 mcelog: STATUS bd80000000100134 MCGSTATUS f May 27 15:48:58 机器名 mcelog: MCGCAP f000c14 APICID 1e SOCKETID 0 May 27 15:48:58 机器名 mcelog: PPIN 2c6b0193f6fb1bb7 May 27 15:48:58 机器名 mcelog: CPUID Vendor Intel Family 6 Model 85 May 27 15:48:58 机器名 mcelog: warning: 8 bytes ignored in each record May 27 15:48:58 机器名 mcelog: consider an update May 27 15:48:58 机器名 kernel: Memory failure: 0x1a1f914: Killing redis-server:44454 due to hardware memory corruption May 27 15:48:58 机器名 kernel: Memory failure: 0x1a1f914: recovery action for dirty LRU page: Recovered May 27 15:48:58 机器名 kernel: MCE: Killing redis-server:44454 due to hardware memory corruption fault at 7f392cb4a9c01.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.2、CPU温度过高，导致可能降频：
(1) 日志： 复制Jun 2 20:13:29 机器名 kernel: CPU20: Core temperature above threshold, cpu clock throttled (total events = 176720) Jun 2 20:13:30 机器名 kernel: CPU48: Core temperature above threshold, cpu clock throttled (total events = 176498) Jun 2 20:17:30 机器名 kernel: CPU50: Core temperature above threshold, cpu clock throttled (total events = 177150) Jun 2 20:17:30 机器名 kernel: CPU22: Core temperature above threshold, cpu clock throttled (total events = 177136) Jun 2 20:20:57 机器名 kernel: CPU44: Core temperature above threshold, cpu clock throttled (total events = 269866) Jun 2 20:20:58 机器名 kernel: CPU16: Core temperature above threshold, cpu clock throttled (total events = 269730) Jun 2 20:37:29 机器名 kernel: CPU54: Core temperature above threshold, cpu clock throttled (total events = 33630) Jun 2 20:37:30 机器名 kernel: CPU26: Core temperature above threshold, cpu clock throttled (total events = 33635) Jun 2 20:45:29 机器名 kernel: CPU17: Core temperature above threshold, cpu clock throttled (total events = 214231) Jun 2 20:45:30 机器名 kernel: CPU45: Core temperature above threshold, cpu clock throttled (total events = 214140)1.2.3.4.5.6.7.8.9.10. (2) 基础知识关于CPU功耗管理，有以下几种模式：
复制performance 运行于最大频率 powersave 运行于最小频率 userspace 运行于用户指定的频率 ondemand 按需快速动态调整CPU频率， 一有cpu计算量的任务，就会立即达到最 大频率运行，空闲时间增加就降低频率 conservative 按需快速动态调整CPU频率， 比 ondemand 的调整更保守 schedutil 基于调度程序调整 CPU 频率1.2.3.4.5.6.查看当前支持模式：
复制$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors performance powersave1.2.查看当前使用模式：
复制$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor performance1.2. (3) 代码分析：内核代码：cpu温度超过阈值会打印系统日志，但是是否降频还和 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor模式有关。
图片
五、总结：
本文粗浅分析了在Redis使用过程中遇到的诡异慢查询问题，其中包含了硬件故障相关，系统参数错误优化等问题，当然实际在使用和运维过程中可能还有其他诡异情况，需要具体问题具体分析。
相关文章
精彩导读
热门资讯
关注我们
