2021-04-29

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

一：背景

1. 讲故事

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

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

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

从图中可以看出，9点开始内存直线暴涨，绝对惊心动魄，要是我的小诺安这样暴涨就好了🤑🤑🤑，接下来 windbg 说话。

二： windbg 分析

1. 说一下思路

内存暴涨了，最怕的就是 非托管层 出了问题，它的排查难度相比 托管层 要难10倍以上，所以遇到这类问题，先祈祷一下吧，gc堆也罢，loader堆也不怕，所以先看看是否 进程内存 ≈ gc堆内存 ?

2. 排查托管还是非托管

排查方式也很简单，通过 !address -summary 看看进程的已提交内存，如下输出：

0:000> !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotalMEM_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 -gcNumber of GC Heaps: 8------------------------------Heap 0 (0000000002607740)generation 0 starts at 0x00000001aaaa5500generation 1 starts at 0x00000001aa3fd070generation 2 starts at 0x0000000180021000Heap 7 (0000000002713b40)generation 0 starts at 0x000000053b3a2c28generation 1 starts at 0x000000053a3fa770generation 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 -statStatistics:    MT Count TotalSize Class Name000007fef7b5c308 32867  788808 System.DateTime000007fef7b5e598 33049  793176 System.Boolean000007feec7301f8 30430  1217200 System.Web.HttpResponseUnmanagedBufferElement000007fef7b56020  2931  3130928 System.Object[]000007fef7b580f8 219398  5265552 System.Int32000007fe9a0c5428 46423  7799064 xxx.Laundry.Entities.V_InvoiceInfo000007fef7b59638 164418  7892064 System.Text.StringBuilder000007fef7b56980 164713  10059852 System.Char[]000007fef7b5a278  7351  26037217 System.Byte[]000007fe9a0d8758  35  28326856 xxx.Laundry.Entities.V_ClothesTagInfo[]0000000002536f50 76837  77016088  Free000007fe9a327ab0 46534 312964608 xxx.Laundry.Entities.V_InvoiceClothesInfo[]000007fe9a0c4868 2068912 397231104 xxx.Laundry.Entities.V_ClothesTagInfo000007fef7b55b70 98986851 3483764540 System.String000007fe9a10ef80 23998759 3839801440 xxx.Laundry.Entities.V_InvoiceClothesInfoTotal 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  Size0000000180027800 000007fe9a10ef80  160  0000000180027910 000007fe9a10ef80  160  0000000180027a20 000007fe9a10ef80  160  0000000180027b30 000007fe9a10ef80  160  Statistics:    MT Count TotalSize Class Name000007fe9a10ef80  4   640 xxx.Laundry.Entities.V_InvoiceClothesInfoTotal 4 objects

4. 查找引用根

接下来用 !gcroot 随便找一个 address 查看它的引用链，看看它到底被谁引用着？

0:000> !gcroot 0000000180027800HandleTable: 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_InvoiceClothesInfoFound 1 unique roots (run '!GCRoot -all' to see all roots).

从输出中可以看到，它貌似被一个 List<BaseModel> 所持有，哈哈，总算找到了，接下来就简单了，直接用 !objsize 看一看它的 size 有多大？

0:000> !objsize 00000004800238a0sizeof(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









原文转载：http://www.shaoqun.com/a/713745.html

跨境电商：https://www.ikjzd.com/

landing：https://www.ikjzd.com/w/2368

好卖家：https://www.ikjzd.com/w/776


一：背景1.讲故事我在年前写过一篇关于CPU爆高的分析文章再记一次应用服务器CPU暴高事故分析，当时是给同济做项目升级，看过那篇文章的朋友应该知道，最后的结论是运维人员错误的将IIS应用程序池设成32bit导致了事故的发生，这篇算是后续😂😂😂，拖了好久才续上哈。犹记得那些天老板天天找我们几个人开会，大概老板是在传导甲方给过来的压力，人倒霉就是这样，你说CPU爆高可怕吧，我硬是给摁下去了，好了
easel：https://www.ikjzd.com/w/1721
心怡科技：https://www.ikjzd.com/w/1327
trax：https://www.ikjzd.com/w/1489
亚马逊选品：https://www.ikjzd.com/w/1042
Facebook营销策略：独立站流量转化终极答案：https://www.ikjzd.com/home/132459
新增190万新卖家？！这个平台"疯"了：https://www.ikjzd.com/home/133990
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)