使用WinDbg偵錯CPU使用率過高原因
昨天同事回報，主機上IIS 的CPU不定時衝高50~99%。本想說dump w3wp.exe回來使用WinDbg偵錯。但它間歇性的衝高，一下子就回復了，所以很難dump到在CPU衝高的狀態。幸好微軟提供了針對此狀況的dump工具「Procdump」，用來監控特定的process，當超過CPU設定值後自動dump。
Procdump Download & Setup
- 安裝後，在開始功能列會看到32及64位元的ICON
- 使用管理者執行cmd
- -ma 包含所有ram、thread的信息
- -r 讓目前的w3wp可以在不用暫停的情況下dump，缺點是會花費較長的時間dump
- 17488 為w3wp.exe的Process Id
- -c 50 cpu超過50%
- -s 3 持續超過3秒
- -n 工具退出前要抓取多少個dump文件，例:設-n 2 代表會等觸發了2次dump文件後關閉監控
D:\Downloads\Procdump\procdump.exe -ma -r -c 50 -s 3 -n 1 17488 -o D:\dumpfile
WinDbg Download & Setup
Dump的檔案，可以透過WinDbg分析除錯
只勾選一個Debugging Tools for Windows
WinDbg Command
1.先載入dumpfile
2.設定路徑，由微軟網站下載分析需要的Symbol檔
.sympath srv*D:\Temp\debug\RTX64_SYMBOLS*https://msdl.microsoft.com/download/symbols
3. 指定顯示完整Symbol下載資訊
!sym noisy
4. 載入 CLR 偵錯相關模組
.cordll -ve -u -l
5. 找出佔用 CPU 最多的 Thread，本案例中，Thread 29為使用最長的時間
!runaway
將偵錯對象切換成 Thread 29，
~29s
6. 使用 !clrstack 列出 Thread 29 的 Callstack，紅框為cpu 會衝高的測試程式。
!clrstack
其他
- 以上1~5每次偵錯dumpfile都要執行一次。
- dumpfile 觸發時，所有的執行緒將被暫停10~50秒，直到 dump完成。
- -r 參數可以不用暫停，只是會dump很久，測試為3分鐘
- 上面的Command及說明參考來自黑暗執行緒好文
- 使用!clrstack 若得到訊息:GetFrameContext failed: 1，改用:!dumpstack。
- ~* e!clrstack 列出所有Thead資訊
補充-使用DebugDiag Tools
WinDbg的功能強大，可以Trace更Detail資訊，但使用上較複雜。微軟也有提另一個簡易分析工具DebugDiag Tools，可以針對dump file直接分新CPU,RAM,Hand住問題等。
另外它也可以類似Procdump的功能來監測cpu作dump。不過這需要安裝。所以我還是傾向用Prodump，將檔案copy到主機，下下命令即可以使用。
更多介紹請參考如下連結:
