利用windbg查找dictionary導致IIS占CPU100%案例分析(一)


一.背景

先說下windbg使用場景.各位coder在工作中或多或少都會遇到下面四種情況

1.本地代碼好好的,放服務器上運行一段時間后,IIS服務突然占用 w3wp.exe CPU突然100% ,不得不回收應用程序池,如果哪次回收晚了,被客戶發現,后果很痛苦~

2.你的w3wp.exe 內存高居不下 並且逐步上升

3.cpu很低,內存也很低,但你的網頁打開卻越來越慢,而你該做的優化都做過了,卻沒有任何效果..

4.你的程序本地運行好好的,但是到服務器上了,在某個時候會突然報錯,再次刷新卻又好了。而偏偏是客戶操作的報錯,你自己訪問正常,會讓你非常苦惱。

 

而最痛苦的是,你是負責維護的,剛接手項目沒多久,不懂技術的老板直接就讓你解決,根本不管這代碼是不是你寫的(我目前就這環境)。上述情況第四點 還有 會有一些系統日志等幫你分析,而前三點則沒有任何

報錯信息等供你參考,加上上萬行的代碼不是你寫的,你根本不可能一行行的去看...這個時候 windbg就可以用上了~~

 

二.問題描述以及工具准備

老板:有個項目w3wp.exe CPU100%了 到時網頁打開非常慢,你趕緊去看下,今天處理好...

我:呵呵..

最近的工作全是這樣,什么CPU100,內存滿了等 因為代碼不是我寫的,寫這個代碼的3年前就走了...於是開始准備神奇windbg

這里一定要注意 windbg 有32位和64位 不要下載錯了。微軟官網即可下載到,不過現在是在線安裝的,會裝其他很多東西,而且安裝的很慢..

於是,登錄到生產環境上,如果你很幸運,是win2008 服務器,自帶的就有抓dump.那么點擊任務管理器,找到CPU100%的進程,然后右鍵創建轉儲文件,稍等片刻后,dump就抓下來了~

如果你是win03服務器,也沒關系,后面告訴你抓去方式~

下面是下載包地址

微軟官方在線安裝下載地址:http://msdn.microsoft.com/en-us/windows/hardware/hh852365

獨立快速安裝包:http://download.csdn.net/detail/zhang957411207/4750492

64位離線安裝包:http://download.csdn.net/detail/lazry/5555291

 

三.分析開始

 1.先通過windbg打開dump包  並設置好符號文件

 2.載入sos.dll  執行.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.DLL
( 我是4.0 的 注意版本 64位)

 3.執行幾個常見指令 開始分析  我總結下 cpu問題 執行這幾個指令 

   !threadpool  查看當前CPU狀況 線程數等等 

   !runaway  查看那幾個線程使用的高 建議多抓幾個dump 然后確定到底是哪個線程

   ~線程IDs 跳轉到那個線程

   !clrstack 看看這個線程再干嘛 執行那些方法

   !clrstack -p  具體方法的參數值地址

   !do 地址  查看參數值

   這樣問題基本就能找到了  下面看實際操作圖

 

四.解決

好了,看到最后都是停留在字典類的操作上

就是這些對字典的操作導致CPU100%..windbg只能幫你到這里了。調試重要的是思想,不是工具。

可是這些字典的操作,為啥么會導致CPU100% 很平常的操作啊  這時看下源碼..發現字典是靜態的  這個靜態字典做緩存。這是很多人的做法...代碼大概都是這樣

 

於是,微微一笑...你們啊,畢竟還是圖樣圖森破..只知道字典做緩存,卻不知道這種情況要考慮線程安全么...字典類不是線程安全的 所以導致CPU。為了印證猜想

去搜了一下 MSDN上有介紹  字典類型導致CPU100%

http://blogs.msdn.com/b/tess/archive/2009/12/21/high-cpu-in-net-app-using-a-static-generic-dictionary.aspx

復合猜想,猜想正確.果然是這樣的原因。

於是果斷使用了.net4.0提供的線程安全的字典類 ConcurrentDictionary  也可以使用lock解決~

從此..世界太平了

 

順便說下  不要一聽到CPU100% 都說死循環導致的 誰沒事寫死循環啊... 很多時候 都是各種阻塞造成的 IO阻塞等   看似很平常的代碼 都會造成CPU100%的~

 

五.配合windbg使用的工具

有的時候 我們希望在程序出錯時 或者CPU100%時 等情況時 自動抓去dump  這個時候 可以使用

Debug Diagnostic Tool   用這個可以自動抓取 並且自帶分析功能 非常方便 支持各種操作系統 解決上面只能08的問題

其次 分析系統問題 有的時候非常復雜 因為有可能會遇到不是代碼引起的,這個時候一定要利用好 windows自帶的性能檢測

利用好這個 會給你分析帶來很大的靈感~

(比如 因為配置文件 config 配置的debug=true 導致的問題 )

 

 

六.后續

如果你的程序員也正在受到上面介紹的4種情況困擾,可以把dump抓下來給我,我可以幫忙分析修改

一個只要1塊錢 長期包年幫忙解決 只要12元 還贈送價值22元的無空格鍵盤....你還等什么....前10個聯系的更有1折優惠,對,你沒聽錯,就是1折...趕緊發短消息聯系我吧...

 下一篇 內存高的案例分析

最后 真誠提前祝大家新年快樂!!

QQ群推薦 33353329


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM