报错kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s

时间:2024-03-05 08:51:11

客户三台云主机报错如下:

 

 

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

Soft lockup名称解释:所谓,soft lockup就是说,这个bug没有让系统彻底死机,但是若干个进程(或者kernel thread)被锁死在了某个状态(一般在内核区域),很多情况下这个是由于内核锁的使用的问题。         

Linux内核对于每一个cpu都有一个监控进程,在技术界这个叫做watchdog(看门狗)。通过ps –ef | grep watchdog能够看见,进程名称大概是watchdog/X(数字:cpu逻辑编号1/2/3/4之类的)。

这个进程或者线程每一秒钟运行一次,否则会睡眠和待机。这个进程运行会收集每一个cpu运行时使用数据的时间并且存放到属于每个cpu自己的内核数据结构。在内核中有很多特定的中断函数。

这些中断函数会调用soft lockup计数,他会使用当前的时间戳与特定(对应的)cpu的内核数据结构中保存的时间对比,如果发现当前的时间戳比对应cpu保存的时间大于设定的阀值,他就假设监测进程或看门狗线程在一个相当可观的时间还没有执。

Cpu软锁为什么会产生,是怎么产生的?如果linux内核是经过精心设计安排的CPU调度访问,那么怎么会产生cpu软死锁?那么只能说由于用户开发的或者第三方软件引入,看我们服务器内核panic的原因就是qmgr进程引起。

因为每一个无限的循环都会一直有一个cpu的执行流程(qmgr进程示一个后台邮件的消息队列服务进程),并且拥有一定的优先级。

Cpu调度器调度一个驱动程序来运行,如果这个驱动程序有问题并且没有被检测到,那么这个驱动程序将会暂用cpu的很长时间。

根据前面的描述,看门狗进程会抓住(catch)这一点并且抛出一个软死锁(soft lockup)错误。软死锁会挂起cpu使你的系统不可用。

 

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

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

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

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

* 服务器电源供电不足,导致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.

* vcpus超过物理cpu cores
https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

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

* 虚机的的CPU太忙或磁盘IO太高
https://www.centos.org/forums/viewtopic.php?t=60087

* BIOS KVM开启以后的相关bug,关闭KVM可解决,但关闭以后物理机不支持虚拟化
https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

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

* BIOS开启了超频,导致超频时电压不稳,容易出现CPU死锁
https://ubuntuforums.org/showthread.php?t=2205211

* Linux kernel存在bug
https://unix.stackexchange.com/questions/70377/bug-soft-lockup-cpu-stuck-for-x-seconds

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

* 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可解决

* 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

* BIOS spread spectrum开启导致
当主板上的时钟震荡发生器工作时,脉冲的尖峰会产生emi(电磁干扰)。spread spectrum(频展)设定功能可以降低脉冲发生器所产生的电磁干扰,脉冲波的尖峰会衰减为较为平滑的曲线。
如果我们没有遇到电磁干扰问题,建议将此项设定为disabled,这栏可以优化系统的性能表现和稳定性;
否则应该将此项设定为enabled。 如果对cpu进行超频,必须将此项禁用。因为即使是微小的脉冲值漂移也会导致超频运行的cpu锁死。
再次强调:CPU超频时,SPREAD SPECTRUM必须关闭,否则容易出现锁死cpu的情况。

 

说白了就是cpu锁死了,系统不能用,重启即可。(经分析,可能客户在服务器上跑大量高负载程序,导致cpu占用过高)

 

 

如果确认不是软件或者程序问题的问题。

解决办法:

追加到配置文件中

#]echo  30  >  /proc/sys/kernel/watchdog_thresh 

#] tail  -1  /proc/sys/kernel/watchdog_thresh
30

临时生效

#]sysctl -w kernel.watchdog_thresh=30

 永久生效

#]vim /etc/sysctl.conf

kernel.watchdog_thresh=30

 

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