记一次 .NET某新能源MES系统非托管泄露

最新推荐文章于 2024-04-23 09:32:23 发布

一线码农

最新推荐文章于 2024-04-23 09:32:23 发布

阅读量149

点赞数

文章标签： .net windbg c# 性能优化

本文链接：https://blog.csdn.net/huangxinchen520/article/details/133268588

版权

一：背景

1. 讲故事

前些天有位朋友找到我，说他们的程序有内存泄露，跟着我的错题集也没找出是什么原因，刚好手头上有一个 7G+ 的 dump，让我帮忙看下是怎么回事，既然找到我了那就给他看看吧，不过他的微信头像有点像 二道贩子，不管到我这里是不是 三道，该分析的还得要分析呀。😄😄😄

二：WinDbg 分析

1. 到底是哪里的泄露

这个非常简单，对用户态内存段做一个分组处理就明白了，可以用 windbg 的 !address -summary 观察便知。


0:000> !address -summary
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                  44571     7ffc`f0900000 ( 127.988 TB)           99.99%
<unknown>                             77531        2`47cee000 (   9.122 GB)  74.52%    0.01%
Heap                                  16406        0`a45cf000 (   2.568 GB)  20.98%    0.00%
Image                                  2116        0`15ad7000 ( 346.840 MB)   2.77%    0.00%
Stack                                  2286        0`0d160000 ( 209.375 MB)   1.67%    0.00%
TEB                                     762        0`005f4000 (   5.953 MB)   0.05%    0.00%
Other                                    39        0`00207000 (   2.027 MB)   0.02%    0.00%
PEB                                       1        0`00001000 (   4.000 kB)   0.00%    0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE                              44571     7ffc`f0900000 ( 127.988 TB)           99.99%
MEM_COMMIT                            86575        1`e571e000 (   7.585 GB)  61.96%    0.01%
MEM_RESERVE                           12566        1`29fd2000 (   4.656 GB)  38.04%    0.00%

从卦中可以清晰的看到 MEM_COMMIT=7.5G 同时 Heap=2.5G，说明可能是托管内存泄露，接下来用 !eeheap -gc 观察下托管堆内存。


0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000020F1BC03E80
generation 1 starts at 0x0000020F1AFE7BA0
generation 2 starts at 0x0000020D2E4B1000
ephemeral segment allocation context: none
Small object heap
         segment             begin         allocated         committed    allocated size    committed size
0000020D2E4B0000  0000020D2E4B1000  0000020D3E4B0000  0000020D3E4B0000  0xffff000(268431360)  0xffff000(268431360)
0000020D09830000  0000020D09831000  0000020D1982FFE0  0000020D19830000  0xfffefe0(268431328)  0xffff000(268431360)
0000020D9D9E0000  0000020D9D9E1000  0000020DAD9DFFB8  0000020DAD9E0000  0xfffefb8(268431288)  0xffff000(268431360)
0000020DD50C0000  0000020DD50C1000  0000020DE50BFFB0  0000020DE50C0000  0xfffefb0(268431280)  0xffff000(268431360)
0000020E10B90000  0000020E10B91000  0000020E20B8FF10  0000020E20B90000  0xfffef10(268431120)  0xffff000(268431360)
0000020E54C60000  0000020E54C61000  0000020E64C60000  0000020E64C60000  0xffff000(268431360)  0xffff000(268431360)
0000020E9C050000  0000020E9C051000  0000020EAC04FF70  0000020EAC050000  0xfffef70(268431216)  0xffff000(268431360)
0000020ED89B0000  0000020ED89B1000  0000020EE89AFF20  0000020EE89B0000  0xfffef20(268431136)  0xffff000(268431360)
0000020F11FF0000  0000020F11FF1000  0000020F1C20E0A8  0000020F1C21A000  0xa21d0a8(169988264)  0xa229000(170037248)
Frozen object heap
         segment             begin         allocated         committed    allocated size    committed size
Large object heap starts at 0x0000020D3E4B1000
         segment             begin         allocated         committed    allocated size    committed size
0000020D3E4B0000  0000020D3E4B1000  0000020D460B3F00  0000020D460D4000  0x7c02f00(130035456)  0x7c23000(130166784)
0000020D72620000  0000020D72621000  0000020D7A19C808  0000020D7A19D000  0x7b7b808(129480712)  0x7b7c000(129482752)
0000020D7CFD0000  0000020D7CFD1000  0000020D84B0CDF0  0000020D84B2D000  0x7b3bdf0(129220080)  0x7b5c000(129351680)
0000020E08B90000  0000020E08B91000  0000020E0FAC4350  0000020E0FAC5000  0x6f33350(116601680)  0x6f34000(116604928)
0000020F2A040000  0000020F2A041000  0000020F2DB4A738  0000020F2DB4B000  0x3b09738(61904696)  0x3b0a000(61906944)
Total Allocated Size:              Size: 0xabf0bd10 (2884680976) bytes.
Total Committed Size:              Size: 0xabf5a000 (2885001216) bytes.
------------------------------
GC Allocated Heap Size:    Size: 0xabf0bd10 (2884680976) bytes.
GC Committed Heap Size:    Size: 0xabf5a000 (2885001216) bytes.

从卦中数据看当前托管堆也才 2.8G，这就比较懵逼了，看样子还是比较难搞的 非托管内存泄露，内存大概被 heap + VirtualAlloc/FileMap 合力吃掉了，接下来该怎么分析呢？有点迷茫。。。

2. 还有其他突破口吗

一般来说这种问题看dump效果已经很不好了，比较好的方式就是用 perfview 去监控 VirtualAlloc，HeapAlloc 分配，但现在可惜的是我们只有一个dump，怎么办呢？ Windbg 命令除了可以看 ntheap，还可以看 clr 的私有堆，即 loader堆，或许有什么新的发现，可以使用命令 !eeheap -loader 。


0:000> !dumpdomain
--------------------------------------
System Domain:      00007fffeb742af0
...
--------------------------------------
Domain 1:           0000020d2c794430
Assembly:           0000020d59298350 [mr4vbdbg, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader:        0000020D579778E0
SecurityDescriptor: 0000020D593DE320
  Module
  00007fff8f0a5af8    mr4vbdbg, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

Assembly:           0000020d5751b040 [51buoqnx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader:        0000020D57974130
SecurityDescriptor: 0000020D593E0060
  Module
  00007fff8f059798    51buoqnx, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Assembly:           0000020d5751c000 [r2bjpfrk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader:        0000020D579741E0
SecurityDescriptor: 0000020D593DF340
  Module
  00007fff8f05aff8    r2bjpfrk, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Assembly:           0000020d5929acf0 [qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]
ClassLoader:        0000020D57976B20
SecurityDescriptor: 0000020D593DD6F0
  Module
  00007fff8f0a11d8    qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
...
Total size:      Size: 0x0 (0) bytes.
--------------------------------------
Total LoaderHeap size:   Size: 0x50f6d000 (1358352384) bytes total, 0x2f43000 (49557504) bytes wasted.
=======================================

我去，不看不知道，一看吓一跳，刷了好久也没刷完，，，看了下总大小是 1.35G，说明当前程序存在着程序集泄露，而且程序集的名字也是奇奇怪怪的比如上面的 r2bjpfrk , qgt1j2cs, 看样子都是动态生成出来的。

这里要提醒一下的是，不要看这里面是 1.35G，它还会涉及到其他未被关联到的内存，比如 VirtualAlloc/MapFile/GCHeap 等等

接下来抽几个 module 看看里面都定义了什么，使用 !dumpmodule -mt 命令即可。


0:000> !dumpmodule -mt 00007fff8f0a11d8
Name: qgt1j2cs, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
Attributes:              PEFile 
Types defined in this module

              MT          TypeDef Name
------------------------------------------------------------------------------
00007fff8f0a1938 0x02000002 ServiceBase.WebService.DynamicWebLoad.xxxImplService

Types referenced in this module

              MT            TypeRef Name
------------------------------------------------------------------------------
00007fffc3232730 0x02000001 System.Web.Services.Protocols.SoapHttpClientProtocol
00007fffe81789e0 0x02000002 System.IAsyncResult
00007fffe81759d8 0x02000003 System.AsyncCallback
00007fffe15f42f8 0x02000004 System.Xml.Serialization.XmlElementAttribute
00007fffe57810a8 0x02000007 System.CodeDom.Compiler.GeneratedCodeAttribute
00007fffe80ee5f8 0x02000008 System.Diagnostics.DebuggerStepThroughAttribute
00007fffe5780210 0x02000009 System.ComponentModel.DesignerCategoryAttribute
00007fffc3239d60 0x0200000a System.Web.Services.WebServiceBindingAttribute
00007fffc323a2f8 0x0200000b System.Web.Services.Protocols.WebClientProtocol
00007fffc32322d8 0x0200000c System.Web.Services.Protocols.SoapDocumentMethodAttribute
00007fffe80f5dd8 0x0200000d System.Object
00007fffe80f59c0 0x0200000e System.String

经过一顿搜索，发现模块中都是这些内容，仔细分析 TypeDef Name 和 TypeRef Name，大概就能猜测到，代码中有 SoapHttpClient 去访问这个 xxxImplService 类名的服务地址，有了这些信息就可以分析源码了。