WinDbg調試分析 asp.net站點 CPU100%問題
公司為了節省成本，最近有一批服務器降了配置，CPU從8核降到了2核。本身是小站點，訪問量也不高，CPU總是會飆到100%而且可以一直持續幾個小時，直接強制結束進程可以維持幾個小時，幾個小時後又一樣，運維那邊總是受到cpu的警告短信很是苦惱，按理來說就算降低了配置也不至於會讓CPU一直100%。
以下就分享本次使用 WinDbg 找出 CPU 100％ 問題的經驗：
1.創建Dump文件
進程註意是32位的，還是64位。64位的進程可以直接創建，32位進程請使用C:\Windows\SysWOW64\taskmgr.exe 任務管理器進行創建，否則放到windbg中會報錯。
2.用windbg載入dump文件
32位的進程使用x86的windbg加載，64為的進程使用x64的windbg來加載。下載地址https://github.com/LonelyCodelang/Tools/tree/master/Windbg_x86_x64
3.配置調試環境
打開後，會顯示程序當時運行所在的環境，此時，會提示符號文件沒有發現：
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
如果不配置，使用命令的時候會提示錯誤，比如：
0:000> .loadby sos clrjit 0:000> !tp *** ERROR: Symbol file could not be found. Defaulted to export symbols for clr.dll - ************* Symbol Loading Error Summary ************** Module name Error clr PDB not found : e:\appserver\symbols\dll\clr.pdb
e:\appserver 是我的dmp文件所在的目錄，它默認是到symbols 子目錄去找符號文件去了。
然後，配置下使用此文件的調試環境。
在菜單命令 File->Symbol path... 打開對話框，選擇瀏覽，找到dmp文件所在目錄相關的程序文件目錄 E:\AppServer ，該目錄下面有程序相關的 exe,pdb 文件。
輸入下面的命令：
0:000> .sympath+ c:\symbols Symbol search path is: E:\AppServer;c:\symbols Expanded Symbol search path is: e:\appserver;c:\symbols Error: Attempts to access ‘c:\symbols‘ failed: 0x2 - 系統找不到指定的文件。 ************* Symbol Path validation summary ************** Response Time (ms) Location OK E:\AppServer Error
這裏不用管，這個文件夾後面可以生成。
0:000> .symfix 0:000> .symfix+ c:\symbols 0:000> .sympath Symbol search path is: srv* Expanded Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred
這下對了。
執行下 reload命令：
0:000> .reload ................................................................ ................................................................ ............
接著執行下面：
0:000> .loadby sos clr 0:000> !tp The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR Version: 4.0.30319.296 SOS Version: 4.6.96.0 Failed to load data access DLL, 0x80004005
這裏提示說SOS的版本更CLR不匹配，這裏需要找到當時生成Dump文件所在的服務器上的 sos.dll，註意，因為服務器程序是64位的，所以必須在 .Net Framework64 目錄去找，同時把 mscordacwks.dll 文件一起拷貝過來（先暫時不用，下面馬上會講到）。
剛才這個命令執行後，我們驚喜的發現，c:\symbols 目錄自己創建了，並且下載了 clr.pdb等幾個目錄，這是再將剛才服務器上拷貝的 sos.dll, mscordacwks.dll ，放到本地機器的 c:\symbols 目錄下面。
再次執行這幾個命令：
0:000> .reload ................................................................ ................................................................ ............ 0:000> .loadby sos clr 0:000> !tp The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging. CLR Version: 4.0.30319.296 SOS Version: 4.6.96.0 Failed to load data access DLL, 0x80004005
還是報錯，看來 sos.dll 沒有加載正確，用下面的命令：
0:000> .load c:\symbols\sos.dll 0:000> .loadby sos clr 0:000> !tp
這裏load命令必須帶SOS.dll的路徑。加載了它，然後執行 .loadby sos clr ,表示調試.NET托管程序。
開始漫長的等待，程序窗口提示：
*BUSY*
Downloading symbols for [clr.pdb] /
等到相關的符號文件全部下載完畢，終於出現了久違的成功界面：
CPU utilization: 11% Worker Thread: Total: 8 Running: 0 Idle: 8 MaxLimit: 32767 MinLimit: 8 Work Request in Queue: 0 -------------------------------------- Number of Timers: 14 -------------------------------------- Completion Port Thread:Total: 1 Free: 1 MaxFree: 16 CurrentLimit: 0 MaxLimit: 1000 MinLimit: 8
4.找出占用CPU最多的Thread，並切換到改Thread
使用!runaway 找出每個Thread消耗的cpu時間。下圖最耗時的線程ID是17，造成CPU100%的就是此線程。
~17s
切換到此線程
5.使用 !clrstack 列出 Thread 27 的 Callstack
從這裏就可以定位到具體的方案，是RabbitMQ消費方法的線程造成的，具體就可以看內部方法的實現，然後進行優化。
相關參考文章:
https://blogs.msdn.microsoft.com/tess/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine/
https://www.cnblogs.com/bluedoctor/p/4813125.html
https://stackoverflow.com/questions/16422577/sos-does-not-support-the-current-target-architecture/16422887
WinDbg調試分析 asp.net站點 CPU100%問題