一、故障描述

突然发现某云主机无法ssh，业务线宕机，虽然主机处于开机状态，但是管理console VNC无法连入，无法ping通地址，云主机被判定为宕机。

二、排查过程

1）查看宕机记录

使用last -F |grep carsh

last reboot //查看主机起来的时间

2）访问/var/logmessage日期查看宕机前的系统日志，查看是否有告警信息，根据告警信息具体检查

可执行：watch -d -n 1 cat /var/log/messages //实时查看，-d表示高亮不同的地方，-n表示多少秒刷新一次。

发现报错：
kernel: NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [RapidStor:12509]
kernel: NMI watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [RapidStor:12515]

上述报错意味着 Linux 内核处理一个任务的时间太长而无法处理内核空间中的其他任务。watchdog守护程序监视此事件并在登录屏幕和 /etc/messages 中通知用户。




从上图日志，可隐隐看出sdb磁盘的问题可能导致了CPU负载高，watchdog检查到报出soft lockup；但检查历史性能，cpu并不高：

3）查看dmesg查看内核日志

确认内核版本：cat /proc/version_signature //输出如下
Ubuntu 4.4.0-150.176-generic 4.4.179

4）查看/var/log/secure查看安全日志判断是否有人恶意攻击服务器

secure里没有明显异常，同样有message里关于soft lockup的报错。

5）查看pci：

执行：lspci -vnvn

查看IO性能：

$ iostat -kx 2
$ vmstat 2 10 //一个参数是采样的时间间隔数，单位是秒，第二个参数是采样的次数；参见

其中：r表等待执行的任务数；展示了正在执行和等待cpu资源的任务个数。当这个值超过了cpu个数，就会出现cpu瓶颈。B表等待IO的进程数量；经验值：

如果r经常大于4，且id经常少于40，表示cpu的负荷很重。如果si，so长期不等于0，表示内存不足。
如果disk经常不等于0，且在b中的队列大于3，表示io性能不好。

$ mpstat 2 10
$ dstat --top-io --top-bio1234

6）查看宕机当时的cpu内存情况

使用sar -r -f /var/log/sa/sa日期|more //ubuntu对应的是/var/log/sysstat/sa日期
或
sar -u -f /var/log/sa/sa日期|more //示例如下

如果踢死未开启，可按如下操作：打开文件 /etc/default/sysstat （ubuntu：/etc/sysstat/sysstat）：
sudo vim /etc/defalut/systat
将 ENABLED=”false“ 改为 ENABLED=“true”
重启 sysstat：sudo service sysstat restart
生成文件：sar -o 2 3 //使用-o 加日期值生成文件

7. 查看/var/log.syslog

8）查看是否有task blocked事件

类似于：task java:18777 blocked for more than 120 seconds.

可通过echo 0 > /proc/sys/kernel/hung_task_timeout_secs 去避免这个告警,

或/sbin/sysctl -w kernel.hung_task_timeout_secs = 0，不设置超时时间，IO阻塞运行

9）查看是否有root cause事件

Linux写磁盘时会用到缓存，这个缓存大概是内存的40%，只有当这个缓存差不多用光时，系统才会将缓存中的内容同步写到磁盘中。但是操作系统对这个同步过程有一个时间限制，就是120秒。如果系统IO比较慢，在120秒内搞不定，那就会出现这个异常。这通常发生在内存很大的系统上。

执行：/sbin/sysctl -w vm.dirty_ratio=10 //把系统缓存降低到10%，让一次性刷新的内存量变小，刷新频率变大，默认是20-40。

echo noop > /sys/block/sda/queue/scheduler //修改磁盘的IO调度策略，修改为最基本的noop策略

10）查看是否有oom-killer错误（out of memory）

11）其他参考：

https://blog.csdn.net/u012811805/article/details/117433530?spm=1035.2023.3001.6557&utm_medium=distribute.pc_relevant_bbs_down.none-task-blog-2_defaultOPENSEARCH_{default-6.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task-blog-2}default_OPENSEARCHdefault-6.nonecase

https://www.cnblogs.com/gaoyuechen/p/8595117.html

3、原因分析

1）内核软死锁（soft lockup）bug原因分析

Soft lockup：所谓soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），CPU 超配, CPU负载高或者IO太高，代码报错都会造成这个报错，很多情况下这个是由于内核锁的使用的问题。lockup分为soft lockup和hard lockup。 soft lockup是指内核中有BUG导致在内核模式下一直循环的时间超过10s（根据实现和配置有所不同），而其他进程得不到运行的机会。hard softlockup是指内核已经挂起，可以通过watchdog这样的机制来获取详细信息。

Soft lockup背后的技术原因涉及 CPU 中断和 nmiwatchdog。对于系统上的每个 CPU，都会创建一个看门狗进程。这个进程每秒“唤醒”一次，获取它负责的 CPU 的当前时间戳，并将其保存到 CPU 数据结构中。（参考）watchdog会监控CPU使用时间的信息并同步到kernel，然后内核有个interrupt函数会调用softlockup计数器，把当前时间和收集到的时间进行比较，如果超过一个阈值，则认为watchdog没有收集到CPU使用时间的信息，可以理解为watchdog 对CPU的心跳失败，kernel就会报出soft lockup的报错。

watchdog分为两种，用于检测soft lockup的普通软狗(基于时钟中断)，以及检测hard lockup的NMI狗（基于NMI中断）。
1>：时钟中断优先级小于NMI中断
2>：lockup，是指某段内核代码占着CPU不放。Lockup严重的情况下会导致整个系统失去响应。
soft lockup 和 hard lockup，它们的唯一区别是 hard lockup 发生在CPU屏蔽中断的情况下。大量高负载程序，造成cpu soft lockup；(检测原理单击参看)

修改watchdog检测阈值：
echo 30 > /proc/sys/kernel/watchdog_thresh //修改超时时间，最大可以设置到60
sysctl -w kernel.watchdog_thresh=30
或/etc/sysctl.conf中追加kernel.watchdog_thresh=30

如果当前占有CPU的时间过长，则会在系统日志中输出我们上面看到的那条日志。接下来才是最关键的，就是输出模块信息、寄存器信息和堆栈信息，检查softlockup_panic的值是否为1。如果softlockup_panic为1，则调用panic()让内核挂起，输出OOPS信息；softlockup_panic的值默认竟然是0，所以在出现死锁或者死循环的时候，会一直只输出日志信息，而不会宕机。现场实际并未报出panic信息。

cat /proc/sys/kernel/softlockup_panic //默认是0，CentOS内核的话，对应的文件是/proc/sys/kernel/watchdog_thresh
开启panic：echo “1” > /proc/sys/kernel/panic

2）关于Watchdog？

Watchdog，又称watchdog timer，是计算机可靠性（dependability）领域中一个极为简单同时非常有效的检测（detection）工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。一旦目标发生错误，没来得及重置计数值，watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。

Watchdog的工作方式是事件触发的，它可以对任何合理的事件计数（如CPU指令）。其中时间事件（timeout）最常使用，这也是为什么watchdog又叫做watchdog timer。Watchdog就是一种检测手段，它监视的目标可以是一个进程也可以是整个操作系统。Watchdog的合理性基于这样的假设：一个正常运行的系统，它的执行流应该是可预测的，因此可以在它正常执行路径上设置一些周期性重置watchdog的点；但如果系统发生故障，它可能执行不到下一个重置watchdog的点，此时故障将被watchdog捕捉到。这也就能理解，watchdog对于检测死循环或死锁这类故障非常有效。

NMI watchdog是Linux的开发者为了debugging而添加的特性，但也能用来检测和恢复Linux kernel hang，现代多核x86体系都能支持NMI watchdog。NMI（Non Maskable Interrupt）即不可屏蔽中断，之所以要使用NMI，是因为NMI watchdog的监视目标是整个内核，而内核可能发生在关中断同时陷入死循环的错误，此时只有NMI能拯救它。

NMI watchdog的思想如watchdog一样，仍然是通过计数和阈值进行监控。要打开NMI watchdog，只需要在grub.cfg中添加一句"nmi_watchdog=N"，重启之后NMI watchdog就已经开启了。

Linux中有两种NMI watchdog，分别是I/O APIC watchdog（nmi_watchdog=1）和Local APIC watchdog（nmi_watchdog=2）。它们的触发机制不同，但触发NMI之后的操作是几乎一样的。从名字上看，它们都利用了APIC。（更多参看）

在Linux内核下，当Watchdog启动后，便设定了一个定时器，如果在超时时间内没有对/dev/Watchdog进行写操作，则会导致系统重启。

参考：https://unix.stackexchange.com/questions/388281/how-can-i-detect-whether-an-nmi-watchdog-bug-soft-lockup-is-a-hardware-or-a