發表文章

目前顯示的是 三月, 2019的文章

使用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 參數可以不用暫停…