[Performance] 用 DebugDiag 查 memory leak

[Performance] 用 DebugDiag 查 memory leak

之前都是用 xperf 來查 memory leak(參閱這裡),

但是有時候會遇上莫名其妙的瓶頸…

例如最近常常分析完 stack 之後,xperf 給出來的結果是像下面這樣:

TOP 25:
Alloc       :     1799420,     823868.0 KB
Realloc     :           0
Outstanding :      408507,      12249.4 KB

———————————————————————

ntdll.dll!RtlAllocateHeap

Alloc       :     1787121,     814439.4 KB
Realloc     :           0
Outstanding :      403997,      12001.4 KB
 

 

可以看到上面 12249 KB 的 memory leak 中,

ntdll.dll!RtlAllocateHeap 就佔了 12001 KB…

但…究竟是誰作了什麼事呼叫到 RtlAllocateHeap 了呢?

xperf 卻沒有列出詳細的 stack trace…

這個問題目前我還沒有找出答案…(若有人知道請告訴我 ^^)

 

因為上述問題,有時只好找別的工具來找 memory leak…

像微軟自己的 Debug Diagnostic Tool (DebugDiag) 有時也是不錯用的工具~

這邊就簡單記錄一下如何使用吧~

 

Step 1: 到 DebugDiag 的網頁 下載並安裝 DebugDiag

Step 2: 執行 DebugDiag,選擇 Native (non-.NET) Memory and Handle Leak

debugdiag1  

 

Step 3: 選擇要查 memory leak 的 process…

假設這邊我們要查的是 Everything-1.2.1.371.exe~

debugdiag2  

 

Step 4: 設定收集資料的的時間長短。這邊 DebugDiag 限定至少要 15 分鐘以上~

debugdiag3  

 

Step 5: 設定規則的名字,通常都直接確定就可以了。

debugdiag4  

 

Step 6: 若要立刻開始收集資料,就選擇 Activate the rule now(通常都是選這個啦)

debugdiag5  

 

Step 7: 如果是第一次執行 DebugDiag 的話,通常就會跳出下面的視窗,

詢問關於 symbol path 的設定,也可以之後再去設~這邊通常就是按 Yes~

debugdiag6  

 

Step 8: 全都設定好之後,可以看到如下的畫面~

這個畫面代表規則已經設定好,已經開始追蹤收集資料囉~

DebugDiag 通常會產生兩條規則,

第一條規則是根據設定的時間來追蹤,第二條規則是 process 如果掛掉的話也就停止追蹤。

可以開始做一些測試動作,好讓程式產生 memory leak~

debugdiag7  

 

Step 9: 等設定的時間到之後,DebugDiag 會自動產生 user dump file,並將狀態標示為 Completed~

debugdiag8   

 

Step 10: 在 Leak Rule 上面按滑鼠右鍵,選擇 Analyze Data 開始分析 memory leak~

debugdiag9  

 debugdiag10    

 

Step 11: 分析完了之後,DebugDiag 會產生一個 .mht 檔,並自動用瀏覽器開啟它~

debugdiag11

 

如果 DebugDiag 有找到 memory leak 的話,

通常可以在最上面的 Analysis Summary 那邊看到相關的 warning,

如果有正確的 symbol 的話也會列出相關的函式名稱~

這樣子的話,就可以針對被列出來的函式仔細檢查了,

當然也可以把整個報告都仔細先看過一次,看看 DebugDiag 是否有提供什麼其他的資訊~

 

Tip: 建議在執行 DebugDiag 之前,先停掉 Debug Diagnostic Service (DbgSvc) 這個服務,

並清除掉 C:Program FilesDebugDiagLogs 目錄下的所有檔案,

再執行 DebugDiag 開始做資料收集與分析,比較不會出現奇怪的問題~

 

這次的 DebugDiag 初步使用就到這邊囉~~ :) 

(本頁面已被瀏覽過 400 次)

發表迴響

你的電子郵件位址並不會被公開。