客戶三台雲主機報錯如下：
內核軟死鎖（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