WinDBG 應用實例:找出 ASP.NET CPU 100% 原因

故事是這様的,我們有一批網站搬到新主機出現詭異現象:每隔一段時間某些 IIS AppPool Process 會吃滿 25% CPU 使用量,在 4 核機器這象徵有一條 Thread 陷入無窮迴圈吃光一個 CPU Core 的時間。有時也會出現多個 AppPool 同時發難,每個 Process 吃 25%,把整體 CPU 使用率逼上 50%、75%,甚至 100%。出問題時,該 AppPool 網站仍能使用,但無法透過 IIS 管理回收 AppPool,只能用 TaskManager 砍掉 Process。砍掉 Process 後,系統會乖一陣子,但幾個小時或隔天又復發。

原本正常的程式移到新環境不穩定讓人心慌,很想知道吃光 CPU 的 AppPool 究竟在忙什麼?到底是哪支網頁是老鼠屎?我唯一想到的可用武器是強大但陌生的 WinDbg (Windows Debugger),爬文與一番摸索後居然真讓我成功抓出問題所在,興奮到想轉圈灑花。:P

以下就分享本次使用 WinDbg 找出 CPU 100% 程式來源的經驗:

  1. 使用 TaskManager 產生 Memory Dump 檔
    找出吃光 CPU 的 w3wp.exe Process,叫出右鍵選單執行「Create dump file」 產生記憶體傾印檔。

    有件事要注意,要先釐清 AppPool 是 32 位元還是 64 位元,若為 32 位元需改用 32 位元版 TaskManager,否則 Dump 檔解析出來的資訊會類似 wow64cpu!TurboDispatchJumpAddressEnd+0x598,看不到真實執行位置。32 位元版 TaskManager 位於 C:\Windows\SysWOW64\taskmgr.exe,執行後 Process 名稱應為「Task Manager (32bit)」。

    若 CPU 是不定期飆高一陣子後恢復,SysInternals 有個超好用工具 procdump,遇到 32 位元 Process 時會自動產生 32 位元 Dump 檔,還可以指定「當 CPU 高於 x% 並持續 y 秒時自動產生 Dump 檔」,可多加利用。
  2. 啟用 WinDbg 載入 Dump 檔案
    Windows Debugger 有 32/64 位元之分,請視要分析對象的位元版本選擇對應版本的 WinDbg。
    啟動 WinDbg 後,使用 File / Open Crash Dump 開啟剛才取得的 w3wp.DMP。

    註:Windows Debugger 下載安裝資訊請自行參考 MSDN,此處不多贅述。
  3. WinDbg 的指令既多且雜,有興趣的朋友請參考文件,此處記錄並說明我動用的指令:
    .sympath srv*X:\Symbol*https://msdl.microsoft.com/download/symbols
    分析過程需要 Symbol 檔,指定 WinDbg 自動由微軟網站下載,並 Cache 在 X:\Symbol 目錄避免重複下載
    !sym noisy
    指定顯示完整 Symbol 下載資訊
    .cordll -ve -u  -l
    自動載入 CLR 偵錯相關模組(分析來自其他台機器 Dump 檔時,這招好用) 
  4. 找出佔用 CPU 最多的 Thread,並將偵錯對象切換成該 Thread
    !runaway
    找出每個 Thread 消耗的 CPU 時間,在本案例中,Thread 27 耗用超過一個小時,無疑是吃光 CPU 的兇手
    ~27s
    將偵錯對象切換成 Thread 27

  5. 使用 !clrstack 列出 Thread 27 的 Callstack

兇手現形!MasterPage 中某個共用元件使用 ODP.NET 讀取使用者基本資料,程式卡在 Oracle.DataAccess.Client.OpsSql.ExecuteReader(),有可能等待 Oracle 資料庫回應時陷入無窮迴圈並耗盡 CPU。

陸續分析了幾起案例的 Dump 檔,都能找到一條 Thread 明顯耗用大量 CPU,而 Callstack 問題都指向 Oracle.DataAccess.Client.OpsSql.ExecuteReader(),鎖定問題後推測是網路設備干擾 Oracle 連線的問題(先前看過的症狀都是收到明確錯誤,像這樣 Hang 住的狀況是第一次遇到),避開後問題排除。

就這樣,靠著 WinDbg 漂亮偵破一個看似毫無頭緒的疑案。

呼口號時間:

WinDbg 好威呀!

歡迎推文分享:
Published 20 February 2017 06:15 AM 由 Jeffrey
Filed under:
Views: 17,240



意見

# ronaldlin said on 19 February, 2017 10:28 PM

除了太神拉~我找不到其他詞句。

# Robert Hu said on 19 February, 2017 11:08 PM

IIS 常見的錯誤三寶: Crash, Hang, Memory Leak 可以用微軟自己推出 Debug Diagnostic Toolkit,抓 dump/分析一次搞定

support.microsoft.com/.../how-to-use-the-debug-diagnostics-tool-to-troubleshoot-high-cpu-usage-by-a-process-in-iis

# Jeffrey said on 21 February, 2017 07:38 AM

to Robert Hu, 感謝分享,DebugDiag Tool 真是好東西,已另撰文介紹:blog.darkthread.net/post-2017-02-21-analyze-cpu-high-with-debugdiag-tools.aspx

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<February 2017>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
2627281234
567891011
 
RSS
創用 CC 授權條款
【廣告】
twMVC
最新回應

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication