Linux系统宕机故障排查及原因分析

2021/10/27 7:09:46

本文主要是介绍Linux系统宕机故障排查及原因分析,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

一、故障描述

突然发现某云主机无法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 加日期值生成文件

  1. 查看/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-2defaultOPENSEARCHdefault-6.nonecase&depth_1-utm_source=distribute.pc_relevant_bbs_down.none-task-blog-2defaultOPENSEARCHdefault-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



这篇关于Linux系统宕机故障排查及原因分析的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程