1. 程式人生 > >一次顯式GC導致的High CPU問題處理過程

一次顯式GC導致的High CPU問題處理過程

.cn images 雲服務 obj 日誌 驚人的 什麽 cati ros

項目現場反饋系統出現性能問題,具體表現為:所有的客戶端響應極其卡頓。

第一反應推測,難道是DB層面出現阻塞?檢查v$session會話狀態及等待類型未見異常,應該可以排除DB層面原因導致的可能。

繼續檢查,難道是應用服務器層面出現資源瓶頸?檢查任務管理器,w3wp.exe進程占用在10%-20%之間,整體占用也在30%以下(項目現場服務器環境為某通運營商雲服務器,此處有坑),內存占用不到4G,w3wp.exe只占了1G多點,服務器的內存好像是48G這個應該也不是瓶頸。繼續。。。難道是網絡?顯然不可能。現場小夥伴是在服務器本地localhost訪問。。。那是什麽原因導致的呢?好像無處下手了TXT...

套路的方法用完了,好像沒找出什麽蛛絲馬跡。死馬當成活馬醫,抓個dump看看吧。上傳下載,中間折騰好幾個小時,dump可算是搞來了。。。

先添加到debugdiag分析下吧,Start Analysis之後自己也嘗試分析下看看~

檢查下系統的資源占用情況,what?明明在抓的時候眼瞅是CPU占用很低的,此處是坑嗎。。。看樣子問題8成是出在自家身上了,環境問題隨他去吧~

技術分享

什麽會導致CPU占用這麽高呢?按照Tess的解釋,大概有這麽三種情況,不過好像是還漏了一種情況——程序執行過程中異常過多。

技術分享

添加下Windows性能計數器看看吧,what?瘋了吧。。三個小時GC次數漲了這麽多。。。而且,很神奇的是Gen0-Gen2次數很接近。。。這個好像有點問題,按照之前的印象,應該是Gen0內存GC的次數多才對吧...這個是什麽原因呢?有點詭異。。。(其實分析的時候沒有用這麽長時間的日誌,只是這個比較明顯,就搬過來了~)

技術分享

回頭看看debugdiag解析情況,OK~最起始的位置就是個驚人的警告!no,應該是Error!工具分析的結果是69號線程觸發了GC,I bet ,High CPU應該是GC導致!要是猜錯了的話,,,那就錯了吧~突然發現DebugDiag還是很貼心的,怕我不明白還特意給出了個連接解釋。https://blogs.msdn.microsoft.com/tess/2006/06/22/asp-net-case-study-high-cpu-in-gc-large-objects-and-high-allocation-rates/

看了半天,可能是太水,好像借鑒意義不是很大。。。

技術分享

繼續,那就先看看69號線程在幹啥吧,好像有點怪怪的。。。為啥業務代碼中還會調到GC_Collect呢?反編譯看看吧

技術分享

IL反編譯

果然調了GC_Collect

技術分享

改下看看吧,驗證OK。

一次顯式GC導致的High CPU問題處理過程