0084.O kernel NMI watchdog BUG soft lockup - CPU#2 stuck for %s

当前单主机上部署4个虚拟机，分别运行oceanbase的1台OCP+3台OBserver，虚拟机经常报错“kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck for 31s! [ocp_exporter:74213]”，除出现ocp_exporter的报错，也会出现其它ob组件报错，下文就问题处理过程进行介绍。

问题涉及范围：oceanbase、vmware workstation、linux

0.1 宿主机1台

• CentOS Linux release 7.6.1810 (Core)；

• vmware-workstation 16；

0.2 虚拟机4台

• CentOS Linux release 7.6.1810 (Core)；

• docker 18.03.0-ce;

• OCP 2.5.0;

• ...

• OceanBase 2.2.75。

OCP和OBserver虚拟机经常报类似错误:

Message from syslogd@ob2 at Aug 13 01:03:11 ...
 kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck for 31s! [ocp_exporter:74213]

注: “原因”章节引用来源：https://www.cnblogs.com/fusheng11711/p/10767190.html

内核软死锁(soft lockup) bug原因分析: 

网上找资料分析了一下原因，直接原因是：如果CPU太忙导致喂狗(watchdog)不及时，此时系统会打印CPU死锁信息：

kernel:BUG: soft lockup - CPU#0 stuck for 38s! [kworker/0:1:25758]

kernel:BUG: soft lockup - CPU#7 stuck for 36s! [java:16182]

......

内核参数kernel.watchdog_thresh（/proc/sys/kernel/watchdog_thresh）系统默认值为10。如果超过2*10秒会打印信息，注意：调整值时参数不能大于60。

虽然调整该值可以延长喂狗等待时间，但是不能彻底解决问题，只能导致信息延迟打印。因此问题的解决，还是需要找到根本原因。

可以打开panic，将/proc/sys/kernel/panic的默认值0改为1，便于定位。

网上查找资料，发现引发CPU死锁的原因有很多种：

1)  服务器电源供电不足，导致CPU电压不稳导致CPU死锁

  https://ubuntuforums.org/showthread.php?t=2205211
  
  I bought a small (500W) new power supply made by what I feel is a reputable company and made the swap.
  GREAT NEWS: After replacing the power supply, the crashes completely stopped! 
  I wanted to wait a while just to be sure, but it is now a few weeks since the new powersupply went in, and I haven't had a single crash since.
  The power supply is not something that I would normally worry about, but in this case it totally fixed my problem.
  Thanks to those who read my post, and especially to those who responded.

2) vcpus超过物理cpu cores

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

3) 虚机所在的宿主机的CPU太忙或磁盘IO太高

4) 虚机的的CPU太忙或磁盘IO太高

https://www.centos.org/forums/viewtopic.php?t=60087

5) BIOS KVM开启以后的相关bug，关闭KVM可解决，但关闭以后物理机不支持虚拟化

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

6) VM网卡驱动存在bug，处理高水位流量时存在bug导致CPU死锁

7) BIOS开启了超频，导致超频时电压不稳，容易出现CPU死锁

https://ubuntuforums.org/showthread.php?t=2205211

8) Linux kernel存在bug

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

9) KVM存在bug

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

10) clocksource tsc unstable on CentOS and cloud Linux with Hyper-V Virtualisation

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

 通过设置clocksource=jiffies可解决

11) BIOS Intel C-State开启导致，关闭可解决

https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds
https://support.citrix.com/article/CTX127395
http://blog.sina.com.cn/s/blog_906d892d0102vn26.html

12) BIOS spread spectrum开启导致

• 当主板上的时钟震荡发生器工作时，脉冲的尖峰会产生emi（电磁干扰）。spread spectrum（频展）设定功能可以降低脉冲发生器所产生的电磁干扰，脉冲波的尖峰会衰减为较为平滑的曲线。

•  如果我们没有遇到电磁干扰问题，建议将此项设定为disabled，这栏可以优化系统的性能表现和稳定性；

•  否则应该将此项设定为enabled。如果对cpu进行超频，必须将此项禁用。因为即使是微小的脉冲值漂移也会导致超频运行的cpu锁死。

•  再次强调：CPU超频时，SPREAD SPECTRUM必须关闭，否则容易出现锁死cpu的情况。

3.1 尝试通过设置kernel.watchdog_thresh延迟值

将内核错误的打印时间由10s调整到30s

1) 临时解决办法

#临时生效

sysctl -w kernel.watchdog_thresh=30

#查看当前值

[root@git-node1 data]# tail -1 proc/sys/kernel/watchdog_thresh
30

2) 永久生效

#追加到配置文件中，重启生效

echo 30 > /proc/sys/kernel/watchdog_thresh

3) 设置结果

经检查，该值设置仅是延迟打印报错，并无实质解决问题，报错依旧。

4) 按上述方法将kernel.watchdog_thresh恢复默认值10s

3.2 部署环境调整，降低物理机IO

当前单主机上部署4个虚拟机，分别运行oceanbase的1台OCP+3台OBserver，当前采用普通SCSI，非SSD/闪存盘，通过监控查看宿主机磁盘IO较高，将1 OCP和3 OBserver分别打散到3台宿主机，分布方式host1(1OCP)/host2(ob1+ob2)/host3(ob3),有效降低IO，观察运行数天，问题未重现,问题解决。

虚拟机系统运行报错，宿主机未报错，通过打印延迟设置，并未解决问题，进一步分析发现IO较高，后通过架构调整，将OCP和OBserver打散到3台宿主机，有效降低IO，问题解决。

https://blog.csdn.net/qq262593421/article/details/107142262

https://blog.csdn.net/jiangganwu/article/details/89711354

https://www.cnblogs.com/fusheng11711/p/10767190.html