欢迎光临
我的个人博客网站

记一次 .NET医疗布草API程序 内存暴涨分析


一:背景

1. 讲故事

我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析,当时是给同济做项目升级,看过那篇文章的朋友应该知道,最后的结论是运维人员错误的将 IIS 应用程序池设成 32bit 导致了事故的发生,这篇算是后续😂😂😂,拖了好久才续上哈。

犹记得那些天老板天天找我们几个人开会,大概老板是在传导甲方给过来的压力,人倒霉就是这样,你说 CPU 爆高可怕吧,我硬是给摁下去了,好了,Memory 又爆高了,尼玛我又给摁下去了,接着数据库死锁又来了,你能体会到这种压力吗?🤣 就像我在朋友圈发的那样,程序再不跑我就要跑了。

记一次 .NET医疗布草API程序 内存暴涨分析

所以有时候敬敬风水还是很有必要的,有点扯远了哈,这篇我们来看看程序的内存暴涨如何去排查,为了让你更有兴趣,来一张运维发的内存监控图。

记一次 .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 查看。

记一次 .NET医疗布草API程序 内存暴涨分析

当然你要保证你有足够的内存,毕竟也算是小10G的dump 🤣, 我的 16G 内存一下子就被吃掉了。。。

记一次 .NET医疗布草API程序 内存暴涨分析

  • 善于用 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

赞(0) 打赏
未经允许不得转载:张拓的天空 » 记一次 .NET医疗布草API程序 内存暴涨分析
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

专业的IT技术经验分享 更专业 更方便

联系我们本站主机

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏