記一次 .NET醫療布草API程式 記憶體暴漲分析

一線碼農發表於2021-04-29

一:背景

1. 講故事

我在年前寫過一篇關於CPU爆高的分析文章 再記一次 應用伺服器 CPU 暴高事故分析,當時是給同濟做專案升級,看過那篇文章的朋友應該知道,最後的結論是運維人員錯誤的將 IIS 應用程式池設成 32bit 導致了事故的發生,這篇算是後續???,拖了好久才續上哈。

猶記得那些天老闆天天找我們幾個人開會,大概老闆是在傳導甲方給過來的壓力,人倒黴就是這樣,你說 CPU 爆高可怕吧,我硬是給摁下去了,好了,Memory 又爆高了,尼瑪我又給摁下去了,接著資料庫死鎖又來了,你能體會到這種壓力嗎?? 就像我在朋友圈發的那樣,程式再不跑我就要跑了。

記一次 .NET醫療布草API程式 記憶體暴漲分析

所以有時候敬敬風水還是很有必要的,有點扯遠了哈,這篇我們來看看程式的記憶體暴漲如何去排查,為了讓你更有興趣,來一張運維發的記憶體監控圖。

從圖中可以看出,9點開始記憶體直線暴漲,絕對驚心動魄,要是我的小諾安這樣暴漲就好了???,接下來 windbg 說話。

二: windbg 分析

1. 說一下思路

記憶體暴漲了,最怕的就是 非託管層 出了問題,它的排查難度相比 託管層 要難10倍以上,所以遇到這類問題,先祈禱一下吧,gc堆也罷,loader堆也不怕,所以先看看是否 程式記憶體 ≈ gc堆記憶體 ?

2. 排查託管還是非託管

排查方式也很簡單,通過 !address -summary 看看程式的已提交記憶體,如下輸出:


0:000> !address -summary

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                                261      7fb`4b151000 (   7.982 TB)           99.77%
MEM_RESERVE                             278        2`6aafc000 (   9.667 GB)  51.35%    0.12%
MEM_COMMIT                             2199        2`4a3a3000 (   9.160 GB)  48.65%    0.11%

可以看到已提交記憶體是 9.1G,接下來看下 gc 堆的大小,使用 !eeheap -gc 即可。


0:000> !eeheap -gc
Number of GC Heaps: 8
------------------------------
Heap 0 (0000000002607740)
generation 0 starts at 0x00000001aaaa5500
generation 1 starts at 0x00000001aa3fd070
generation 2 starts at 0x0000000180021000
Heap 7 (0000000002713b40)
generation 0 starts at 0x000000053b3a2c28
generation 1 starts at 0x000000053a3fa770
generation 2 starts at 0x0000000500021000

------------------------------
GC Heap Size:            Size: 0x1fdfe58c8 (8556271816) bytes.

從最後一行輸出中可以看到當前的佔用是 8556271816 / 1024 /1024 /1024 = 7.9G ,太幸運了,果然是託管層出了問題,gc 上有大塊髒東西,這下有救了 ???。

3. 檢視託管堆

知道託管堆出了問題後,接下來就可以用 !dumpheap -stat 去gc堆上翻一翻。


0:000> !dumpheap -stat
Statistics:
              MT    Count    TotalSize Class Name
000007fef7b5c308    32867       788808 System.DateTime
000007fef7b5e598    33049       793176 System.Boolean
000007feec7301f8    30430      1217200 System.Web.HttpResponseUnmanagedBufferElement
000007fef7b56020     2931      3130928 System.Object[]
000007fef7b580f8   219398      5265552 System.Int32
000007fe9a0c5428    46423      7799064 xxx.Laundry.Entities.V_InvoiceInfo
000007fef7b59638   164418      7892064 System.Text.StringBuilder
000007fef7b56980   164713     10059852 System.Char[]
000007fef7b5a278     7351     26037217 System.Byte[]
000007fe9a0d8758       35     28326856 xxx.Laundry.Entities.V_ClothesTagInfo[]
0000000002536f50    76837     77016088      Free
000007fe9a327ab0    46534    312964608 xxx.Laundry.Entities.V_InvoiceClothesInfo[]
000007fe9a0c4868  2068912    397231104 xxx.Laundry.Entities.V_ClothesTagInfo
000007fef7b55b70 98986851   3483764540 System.String
000007fe9a10ef80 23998759   3839801440 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 126039641 objects

我去,託管堆上的 xxx.Laundry.Entities.V_InvoiceClothesInfo 物件居然高達 2399w ,佔了大概 3.6G,這還不算其附屬物件,對了,如果直接用 !dumpheap -mt xxx 輸出 address 的話,很難進行UI中止,所以這裡有一個小技巧,用 range 來限定一下,如下程式碼所示:


0:000> !dumpheap -mt 000007fe9a10ef80 0 0000000180027b30
         Address               MT     Size
0000000180027800 000007fe9a10ef80      160     
0000000180027910 000007fe9a10ef80      160     
0000000180027a20 000007fe9a10ef80      160     
0000000180027b30 000007fe9a10ef80      160     

Statistics:
              MT    Count    TotalSize Class Name
000007fe9a10ef80        4          640 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 4 objects

4. 查詢引用根

接下來用 !gcroot 隨便找一個 address 檢視它的引用鏈,看看它到底被誰引用著?


0:000> !gcroot 0000000180027800
HandleTable:
    00000000013715e8 (pinned handle)
    -> 000000058003c038 System.Object[]
    -> 00000004800238a0 System.Collections.Generic.List`1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]]
    -> 0000000317e01ae0 xxx.Laundry.APIService.Models.Common.BaseModel[]
    -> 000000028010caf0 xxx.Laundry.APIService.Models.Common.BaseModel
    -> 00000003014cbbd0 System.Collections.Generic.List`1[[xxx.Laundry.Entities.V_InvoiceInfo, xxx.Laundry.Entities]]
    -> 00000003014f3580 xxx.Laundry.Entities.V_InvoiceInfo[]
    -> 00000003014cd7f0 xxx.Laundry.Entities.V_InvoiceInfo
    -> 000000038cc49bf0 System.Collections.Generic.List`1[[xxx.Laundry.Entities.V_InvoiceClothesInfo, xxx.Laundry.Entities]]
    -> 000000038cc49c18 xxx.Laundry.Entities.V_InvoiceClothesInfo[]
    -> 0000000180027800 xxx.Laundry.Entities.V_InvoiceClothesInfo

Found 1 unique roots (run '!GCRoot -all' to see all roots).

從輸出中可以看到,它貌似被一個 List<BaseModel> 所持有,哈哈,總算找到了,接下來就簡單了,直接用 !objsize 看一看它的 size 有多大?


0:000> !objsize 00000004800238a0
sizeof(00000004800238a0) = -1972395312 (0x8a6fa2d0) bytes (System.Collections.Generic.List`1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]])


看到上面的 -1972395312 了嗎? 我去,int 型別的 size 直接給爆掉了,果然是個大物件,就是你了。。。如果非要看大小也可以,寫一個指令碼遍歷一下。

三:總結

知道是 List<BaseModel> 做的孽後,仔細閱讀了原始碼才知道,原來是給使用者第一次資料全量同步的時候,服務端為了加速將資料快取在 List<BaseModel> 這個靜態變數中,很遺憾的是並沒有在合適的時機進行釋放,造成了高峰期記憶體直線暴增,優化方案很簡單,就是修改業務邏輯咯,增加釋放記憶體的時機。

題外話

  • 如果你遇到的是這種 Strong Handles 的靜態變數,也可以直接用視覺化的 dotMemory 檢視。

當然你要保證你有足夠的記憶體,畢竟也算是小10G的dump ?, 我的 16G 記憶體一下子就被吃掉了。。。

  • 善於用 String 駐留池機制來優化,看看它的原始碼定義吧。

    public sealed class String
    {
        [SecuritySafeCritical]
        public static string Intern(string str)
        {
            if (str == null)
            {
                throw new ArgumentNullException("str");
            }
            return Thread.GetDomain().GetOrInternString(str);
        }
    }

對於那些重複度很高的string,用駐留池機制可以節省千百倍的記憶體空間,至於為什麼可以優化,可參考我之前的文章:字串太佔記憶體了,我想了各種奇思淫巧對它進行壓縮

更多高質量乾貨:參見我的 GitHub: dotnetfly

相關文章