背景

某天晚上八點多，突然收到一個 CPU 爆表的告警。

過了一會，幾個業務線就開始反饋系統變慢了。

后面緊急處理了這臺機器后，讓業務先恢復正常。

后續看了一下監控，拔涼拔涼的。

這個服務是比較重要的一個老業務，.NET Framework 的 Web API 項目。

回過頭來看一下，要找出造成了 CPU 持續 100% 的根本原因，這樣才能把這個雷去掉。

要分析的話，需要創建了一個 CPU 持續很高的時候的 dump 包，然后用 WinDbg 來處理。

下面來分析一下，探個究竟。

WinDbg 分析

WinDbg分析CPU，用的比較多的其實就那幾個命令。

照著走一遍基本就出來結果了。

首先是用 !threadpool 查看當前CPU狀況和線程信息。

上面主要的是 76% 的 CPU 使用率。

然后是用 !runaway 看線程的耗時，看那個占用多

從上圖可以看出 32 、34 、38 、39 ?這幾個線程比較可疑。

下面就是切換到對應的線程看具體的信息了。

用 ~34s 切換到 34 號線程，如果是其他，按需替換即可。

然后用 !clrstack 看這個線程在執行什么內容

上面的圖很清晰的告訴我們，有一個 ConverAgeMonth 的方法，里面用到了正則。說到正則，用的不好，真的很容易出問題。

到這里基本就知道問題出在那里了。

下面還要看具體的參數信息，才會更加清晰一點。

這里用的是 !clrstack -p 這個命令。

可以看到 ConverAgeMonth 這個方法有兩個參數， age 和 ageMonth。

點一下 age 對應的地址或者手動輸入 !do 地址 就可以看到具體的字符串內容了。

看到這個超級長字符串，長度接近 2w 。。。。

同樣看了其他幾個，都是如出一轍，可以斷定就是那個正則惹的禍了。

后續調整了這一塊的內容后就沒有出現過了 CPU 爆表的情況了。

寫在最后

雖然 WinDbg 用起來感覺很不錯，不過整體流程相對復雜一點，相當于是離線分析，不能實時進行觀測和分析。

這一塊還有待完善，有很大的提升空間。

總結

以上是生活随笔為你收集整理的记一次CPU持续100%及分析方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。