記一次 .NET 醫(yī)療布草 API 程序內(nèi)存暴漲分析

作者：一線碼農(nóng)聊技術(shù) 2021-04-29 07:33:40

我在年前寫過一篇關(guān)于CPU爆高的分析文章再記一次應(yīng)用服務(wù)器 CPU 暴高事故分析，當(dāng)時是給同濟(jì)做項(xiàng)目升級，看過那篇文章的朋友應(yīng)該知道，最后的結(jié)論是運(yùn)維人員錯誤的將 IIS 應(yīng)用程序池設(shè)成 32bit 導(dǎo)致了事故的發(fā)生，這篇算是后續(xù)，拖了好久才續(xù)上哈。

[[396727]]

本文轉(zhuǎn)載自微信公眾號「一線碼農(nóng)聊技術(shù)」，作者一線碼農(nóng)聊技術(shù)。轉(zhuǎn)載本文請聯(lián)系一線碼農(nóng)聊技術(shù)公眾號。

一：背景

1. 講故事

猶記得那些天老板天天找我們幾個人開會，大概老板是在傳導(dǎo)甲方給過來的壓力，人倒霉就是這樣，你說 CPU 爆高可怕吧，我硬是給摁下去了，好了，Memory 又爆高了，尼瑪我又給摁下去了，接著數(shù)據(jù)庫死鎖又來了，你能體會到這種壓力嗎??? 就像我在朋友圈發(fā)的那樣，程序再不跑我就要跑了。

[[396728]]

所以有時候敬敬風(fēng)水還是很有必要的，有點(diǎn)扯遠(yuǎn)了哈，這篇我們來看看程序的內(nèi)存暴漲如何去排查，為了讓你更有興趣，來一張運(yùn)維發(fā)的內(nèi)存監(jiān)控圖。

從圖中可以看出，9點(diǎn)開始內(nèi)存直線暴漲，絕對驚心動魄，要是我的小諾安這樣暴漲就好了，接下來 windbg 說話。

二：windbg 分析

1. 說一下思路

內(nèi)存暴漲了，最怕的就是非托管層出了問題，它的排查難度相比托管層要難10倍以上，所以遇到這類問題，先祈禱一下吧，gc堆也罷，loader堆也不怕，所以先看看是否進(jìn)程內(nèi)存 ≈ gc堆內(nèi)存 ?

2. 排查托管還是非托管

排查方式也很簡單，通過 !address -summary 看看進(jìn)程的已提交內(nèi)存，如下輸出：

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%

可以看到已提交內(nèi)存是 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.

從最后一行輸出中可以看到當(dāng)前的占用是 8556271816 / 1024 /1024 /1024 = 7.9G ，太幸運(yùn)了，果然是托管層出了問題，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 對象居然高達(dá) 2399w ，占了大概 3.6G，這還不算其附屬對象，對了，如果直接用 !dumpheap -mt xxx 輸出 address 的話，很難進(jìn)行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 所持有，哈哈，總算找到了，接下來就簡單了，直接用 !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 直接給爆掉了，果然是個大對象，就是你了。。。如果非要看大小也可以，寫一個腳本遍歷一下。

三：總結(jié)

知道是 List 做的孽后，仔細(xì)閱讀了源碼才知道，原來是給用戶第一次數(shù)據(jù)全量同步的時候，服務(wù)端為了加速將數(shù)據(jù)緩存在 List 這個靜態(tài)變量中，很遺憾的是并沒有在合適的時機(jī)進(jìn)行釋放，造成了高峰期內(nèi)存直線暴增，優(yōu)化方案很簡單，就是修改業(yè)務(wù)邏輯咯，增加釋放內(nèi)存的時機(jī)。

題外話

如果你遇到的是這種 Strong Handles 的靜態(tài)變量，也可以直接用可視化的 dotMemory 查看。

當(dāng)然你要保證你有足夠的內(nèi)存，畢竟也算是小10G的dump ??，我的 16G 內(nèi)存一下子就被吃掉了。。。

善于用 String 駐留池機(jī)制來優(yōu)化，看看它的源碼定義吧。

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