如何分析w3wp占用CPU過高的解決過程

如何分析w3wp占用CPU過高的解決過程，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

項目上線以來一直存在一個比較揪心的問題，和一個沒有信心處理的BUG，那就是在應用程序啟動時有可能會導致cpu跑滿99%或持續在一個值如50%左右，這樣一來對服務器的壓力是非常大的，經常出現服務器無法遠程的狀態，唯有通過PowerShell殺掉對應的w3wp進程才可以解決這個問題。

為什么沒有信心處理這個問題

原因非常簡單，這個問題是間歇性的，不容易重現的，只會在項目啟動時有一定的可能性會發生CPU跑滿的問題。

所有可以重現的BUG的處理都不會太難，而類似這種無法重現的BUG是最讓人頭疼的，因為它無影無蹤，令人難以尋跡。

如何處理這個問題？

1.一開始采用猜的辦法，去項目中找while、lock等關鍵詞，這樣無異于大海撈針，而且不嚴謹的修改還會導致其他更為嚴重的問題產生，很快這個方案在搜尋過一遍后被放棄了。

2.后來記得有用過WinDbg解決過電腦藍屏的問題，就猜想是否可以抓取對應w3wp進程的dump進行分析。

使用WinDbg查找線索

1.由于服務器是2008R2抓取dump就變得異常簡單。

2.使用WinDbg

load SOS.dll后查看線程信息。

發現有7個線程比較耗時，這時候心想我用的線程也是7個，這時候內心無比的激動。

切換到21線程，查看堆棧信息后發現

在Dictionary的Insert時堵塞了，這時候查看其它占時很長的線程狀態，也不外乎是這里堵塞了。

Dictionary中的Insert方法真的會堵塞嗎？

寫下如下測試代碼后運行了幾次

發現真的在有些時候cpu會占的非常高有時候又正常。

那么問題也就明朗了，解決它也變得非常容易，找到GetRoutes代碼，原先是這么實現的

BundleTable.Bundles內部維護了一個靜態字典表，那么問題就呼之欲出了，對這段代碼加鎖。

修改后的代碼

觀測了一段時間后，問題也確實解決了。

Dictionary中的Insert為什么會堵塞

我知道Dictionary不是一個線程安全的類型，但我原本以為Dictionary在非線程安全方式下訪問時數據會錯亂，而不會堵塞或者死鎖，而這次的這個問題讓我感覺到訝異，為什么Add一個項目會造成堵塞？

反編譯Dictionary的源碼后發現異常的復雜，也沒有細究，所以下面的一段描述大家抱有自己的想法去閱讀，可能是錯的也可能是對的。

上面是我認為存在問題的地方，當一個線程執行過Initialize后buckets數組的值被修改，而第二個線程同時進入了Initialize方法，那么第一個線程所維護的值被破壞，造成在算法環節出現了死循環，這也可以說明了為什么cpu有時候是50%有時候是99%的問題。

當前有多少個線程發生了這種狀態，如果發生這種狀態的線程越多則代表cpu占用越多。

關于如何分析w3wp占用CPU過高的解決過程問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。