背景
某天晚上八點多，突然收到一個 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 用起來感覺很不錯，不過整體流程相對複雜一點，相當於是離線分析，不能實時進行觀測和分析。
這一塊還有待完善，有很大的提升空間。