故障描述
2023 年 1 月 30 日 15:32 分，收到 数据库连接访问异常通知，远程连接做紧急恢复处理，由于当时不能正常对数据库做启停操作，故直接强制对操作系统进行重启后恢复业务。
业务恢复后，对 rac 数据库、操作系统进一步排查，判定是由于 watchdog （看门狗）频繁进行 cpu 检测导致大量资源消耗，最终系统负载较高没有充足的资源调配存储 I/O ，致使业务访问数据库异常。
问题详细诊断过程
检查节点一，发现节点一由于网络通信原因遭驱逐，磁盘 I/O 通信也不能正常完成，最终无法获取仲裁盘正确状态，如下图：
检查节点二，节点一被仲裁驱逐。如下：
检查数据库数据访问情况，发现故障时间段（ 15:20-15:30 ）没有访问记录，最新记录有等待 io 记录为 15:13 ，如下图：
这说明，磁盘I/O 已经出现等待，后续业务已经无法顺畅进行操作。
检查操作系统日志，有较多的cpu 自检测延时记录，并且watchdog （看门狗）处理服务超时状态。
故障期间，登陆操作系统发现异常卡顿，检查top 命令发现load average 很高，存在大量进程上下文频繁切换导致load average 过高的情况。说明系统负载已经非常高。
操作系统后台查看watchdog 运行不能及时处理cpu 自检导致超时，watchdog （看门狗）处理频繁、超时会导致cpu 处于高耗状态。高负载的情况下，load average 飙升，操作系统整体性能严重下降，最终影响数据库的正常运行。
解决办法和建议
解决办法：建议 rac 两个节点 关闭watchdog ，减少极端情况下watchdog 对cpu 的性能消耗而影响操作系统正常运行的情况。
检测语句（1为开启，0为关闭）
sysctl kernel.nmi_watchdog
临时关闭
sysctl kernel.nmi_watchdog=0
永久关闭
#
在
/etc/sysctl.conf
中增加如下内容，开机自动关闭
kernel.nmi_watchdog = 0
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23825935/viewspace-2936512/ ，如需转载，请注明出处，否则将追究法律责任。
