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

  • A+
所属分类：.NET技术
摘要

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

一：背景

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

便宜好用的国外VPS推荐