共计 2454 个字符，预计需要花费 7 分钟才能阅读完成。
集体博客: 点击这里进入
1. 景象形容
系统管理员电话告诉，形容为一台服务器忽然无奈 ssh 连贯，登录服务器带外 IP 地址并进入近程控制台界面后，提醒 Authentication error，重启后即可失常进入零碎，进入后过 20 分钟又进入死循环
2. 排查起因
登录零碎后无任何操作报错如下：
询问了度娘，发现此报错为内核锁死，简称“死机”，询问管理员后得悉，近期服务器装置了 docker，可能因为负载过高导致
- Soft lockup：这个 bug 没有让零碎彻底死机，然而若干个过程（或者 kernel thread）被锁死在了某个状态（个别在内核区域），很多状况下这个是因为内核锁的应用的问题。
- 内核参数 kernel.watchdog_thresh（/proc/sys/kernel/watchdog_thresh）零碎默认值为 10。如果超过 2 *10 秒会打印信息，留神：调整值时参数不能大于 60
- 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 使你的零碎不可用。
3. 具体分析
###### 1. 零碎如下工夫 2 个工夫进行了重启:
Mar 3 21:53:16 ser-node7 kernel: Linux version 3.10.0-957.el7.x86_64 (mockbuild@x86040.build.eng.bos.redhat.com)
Mar 3 22:37:19 ser-node7 kernel: Linux version 3.10.0-957.el7.x86_64 (mockbuild@x86040.build.eng.bos.redhat.com) 在重启前的一段时间均曾经呈现了 cpu 软锁的景象，而深入分析 cpu 软锁，咱们依赖于 kdump 产生的 vmcore 数据.
Mar 3 14:28:18 ser-node7 kernel: NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [runc[1:CHILD]:52902]
Mar 2 18:14:59 ser-node7 kernel: NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [runc:[1:CHILD]:55961]./systemctl_list-unit-files:kdump.service enabled
如果您之前曾经做过，那么请您额定批改 /etc/sysctl.conf 退出以下行:
kernel.softlockup_panic = 1
而后执行 ”sysctl -p” 使参数失效。这样当零碎呈现 cpu 软锁景象时，会主动触发 kernel panic，此时如果 kdump 能够失常工作，会生成 vmcore. 并主动重新启动零碎
2. 另外在日志中咱们还留神了存在如下的告警, 其和下面的 soft lockup 问题无间接关系.
# cat messages | grep "SLUB: Unable to allocate memory on node"
Mar 2 18:04:45 ser-node7 kernel: SLUB: Unable to allocate memory on node -1 (gfp=0xd0)
Mar 3 14:54:25 ser-node7 kernel: SLUB: Unable to allocate memory on node -1 (gfp=0xd0)
Mar 3 14:54:25 ser-node7 kernel: SLUB: Unable to allocate memory on node -1 (gfp=0xd0)此为零碎的已知 BUG，具体请参考如下 KB：
- SLUB: Unable to allocate memory on node -1 (gfp=0x20)
https://access.redhat.com/sol…
根据此 KB，请将 kernel 降级到 kernel-3.10.0-1062.4.1.el7 或者更新.- kernel-3.10.0-1062.4.1.el7 下载地址为:
https://access.redhat.com/err…- 如何降级内核，请查看上面文档：
How to update/upgrade the Red Hat Enterprise Linux kernel?
https://access.redhat.com/sol…
4. 解决方案
百度大手子给的计划如下所示：
vi /etc/sysctl.conf
kernel.watchdog_thresh =30- 查看：
# tail -1 /proc/sys/kernel/watchdog_thresh- 长期失效：
# sysctl -w kernel.watchdog_thresh=30
原厂倡议尚在期待中
正文完
