使用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. 以上1~5每次偵錯dumpfile都要執行一次。
  2. dumpfile 觸發時,所有的執行緒將被暫停10~50秒,直到 dump完成。
    1. -r 參數可以不用暫停,只是會dump很久,測試為3分鐘
  3. 上面的Command及說明參考來自黑暗執行緒好文
  4. 使用!clrstack 得到訊息:GetFrameContext failed: 1,改用:!dumpstack。
  5. ~* e!clrstack 列出所有Thead資訊

補充-使用DebugDiag Tools

WinDbg的功能強大,可以Trace更Detail資訊,但使用上較複雜。微軟也有提另一個簡易分析工具DebugDiag Tools,可以針對dump file直接分新CPU,RAM,Hand住問題等。
另外它也可以類似Procdump的功能來監測cpu作dump。不過這需要安裝。所以我還是傾向用Prodump,將檔案copy到主機,下下命令即可以使用。
更多介紹請參考如下連結:


這封郵件來自 Evernote。Evernote 是您專屬的工作空間,免費下載 Evernote

這個網誌中的熱門文章

[TFS] 分支與合併

[TFS] 擱置暫止的變更