一:背景

1. 讲故事

去年十月份有位朋友从微信找到我,说他的程序内存要炸掉了。。。截图如下:

时间有点久,图片都被清理了,不过有点讽刺的是,自己的程序本身就是做监控的,结果自己出了问题,太尴尬了

二:Windbg 分析

1. 托管还是非托管

这个是甄别内存问题的第一步,通过 !address -summary!eeheap -gc 两个命令基本就可以断定。


0:000> !address -summary
Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions... --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 237 7ffc`1e222000 ( 127.985 TB) 99.99%
<unknown> 594 3`b9b20000 ( 14.901 GB) 95.96% 0.01%
Heap 370 0`12a2a000 ( 298.164 MB) 1.88% 0.00%
Image 1248 0`0ee5a000 ( 238.352 MB) 1.50% 0.00%
Stack 315 0`06780000 ( 103.500 MB) 0.65% 0.00%
Other 13 0`001d7000 ( 1.840 MB) 0.01% 0.00%
TEB 105 0`000d2000 ( 840.000 kB) 0.01% 0.00%
PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00% --- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 1178 3`ce03d000 ( 15.219 GB) 98.00% 0.01%
MEM_IMAGE 1409 0`0f6fd000 ( 246.988 MB) 1.55% 0.00%
MEM_MAPPED 59 0`04694000 ( 70.578 MB) 0.44% 0.00% --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 237 7ffc`1e222000 ( 127.985 TB) 99.99%
MEM_COMMIT 2326 3`c7543000 ( 15.115 GB) 97.33% 0.01%
MEM_RESERVE 320 0`1a88b000 ( 424.543 MB) 2.67% 0.00% 0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000009902B57670
generation 1 starts at 0x0000009902A56810
generation 2 starts at 0x00000095318C1000
ephemeral segment allocation context: (0x0000009902D724A8, 0x0000009902D724C0)
segment begin allocated committed allocated size committed size
...
00000098FFBE0000 00000098FFBE1000 0000009902D724A8 0000009902D7D000 0x31914a8(51975336) 0x319c000(52019200)
Large object heap starts at 0x00000095418C1000
segment begin allocated committed allocated size committed size
00000095418C0000 00000095418C1000 00000095475D8D98 00000095475D9000 0x5d17d98(97615256) 0x5d18000(97615872)
Total Allocated Size: Size: 0x398e6cbc8 (15450164168) bytes.
Total Committed Size: Size: 0x398e7b000 (15450222592) bytes.
------------------------------
GC Allocated Heap Size: Size: 0x398e6cbc8 (15450164168) bytes.
GC Committed Heap Size: Size: 0x398e7b000 (15450222592) bytes.

从输出信息看,好家伙。。。进程提交内存是 15G, 托管堆差不多也是 15G,这就说明当前是相对简单的 托管内存泄漏

2. 到底是什么在泄漏

要想知道到底是什么在泄漏,可以先到托管堆上看看有没有什么异常的对象,使用 !dumpheap -stat 命令。


0:000> !dumpheap -stat
Statistics:
MT Count TotalSize Class Name
...
00007ff8815d0f88 7260233 290409320 System.Collections.ArrayList
00007ff8815e6830 7313696 326240826 System.String
000000952fbbd2b0 12141398 509369998 Free
00007ff880685cf0 7254983 928637824 System.Diagnostics.ProcessInfo
00007ff88065f7d0 7256845 2031916600 System.Diagnostics.Process
00007ff8815e6ea8 7391338 2230744600 System.Object[]
00007ff88068fa70 186800748 8966435904 System.Diagnostics.ThreadInfo

从卦象上来看,真的太奇怪了,如果大家了解 Process 类,应该知道 ProcessInfoThreadInfo 都是挂在 Process 下的,而且 ThreadInfo 对象高达 1.8亿,真的太了,看样子程序是在不断的做 Process.Start 操作吧。

接下来要探究的问题是 ThreadInfo 到底正在被谁持有??? 可以挑几个看看它们的 !gcroot, 首尾法查了几个,都是没有引用根,如下所示:


0:000> !gcroot 0000009531e8f760
Found 0 unique roots (run '!GCRoot -all' to see all roots).
0:000> !gcroot 0000009531e8f670
Found 0 unique roots (run '!GCRoot -all' to see all roots).
0:000> !gcroot 0000009531e8f378
Found 0 unique roots (run '!GCRoot -all' to see all roots).

3. 无引用根为什么不被回收

既然对象没有引用根,为什么 GC 不回收它呢? 这里就需要谈经验了,在我之前分析的很多关于内存泄漏 的dump中,我都是从 生产端 找问题,貌似还没有出现一个从 消费端 找问题的案例,参考模型如下:

生产者既然没问题,那消费端能有什么问题呢?大家可以想一想,托管堆的消费端起码有两个角色。

  1. GC

  2. Finalizer 线程

GC 肯定是不会出问题的,那就只能怀疑 Finalizer 线程出了什么问题,可以用 !t 命令把所有线程调出来看看。


0:000> !t
ThreadCount: 9566
UnstartedThread: 0
BackgroundThread: 88
PendingThread: 0
DeadThread: 9471
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 40e18 000000952fbdfe50 26020 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
2 2 41ce8 000000952fc0e4d0 2b220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Finalizer)
4 4 41cb4 000000954c324970 27220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
5 5 41cb8 000000954c36d1e0 2027220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
6 6 41c58 000000954c33f070 2027220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
7 7 41c38 000000954c33f840 27220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
8 8 41e0c 000000954c333580 27220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
9 9 41e2c 000000954c354440 27220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
10 10 41f24 000000954c355840 27220 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 STA
...
XXXX 9446 0 000000957a233410 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9447 0 0000009579f83e30 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9450 0 000000957a46dcf0 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9449 0 000000957967c6e0 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9448 0 000000957aee0010 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9452 0 00000095796824a0 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)
XXXX 9451 0 000000957af05df0 8039820 Preemptive 0000000000000000:0000000000000000 000000952fbd2e40 0 MTA (Threadpool Completion Port)

这不看不知道,一看吓一跳,当前进程有 9566 个,死线程高达 9471 个 ,以过往经验,这小子不用线程池,用 new Thread 咯, ,吐槽结束,再看下 Finalizer 线程正在做什么,使用 ~2s & !dumpstack


0:002> ~2s
ntdll!NtWaitForSingleObject+0xa:
00007ff8`8e220c8a c3 ret
0:002> !dumpstack
OS Thread Id: 0x41ce8 (2)
Current frame: ntdll!NtWaitForSingleObject+0xa
Child-SP RetAddr Caller, Callee
0000009549e4e120 00007ff88b591118 KERNELBASE!WaitForSingleObjectEx+0x94, calling ntdll!NtWaitForSingleObject
0000009549e4e1c0 00007ff88da3e334 combase!MTAThreadWaitForCall+0x54 [d:\9147\com\combase\dcomrem\channelb.cxx:5657], calling KERNELBASE!WaitForSingleObject
0000009549e4e210 00007ff88d8fe089 combase!MTAThreadDispatchCrossApartmentCall+0x75 [d:\9147\com\combase\dcomrem\chancont.cxx:193], calling combase!MTAThreadWaitForCall [d:\9147\com\combase\dcomrem\channelb.cxx:5619]
0000009549e4e240 00007ff88da3e13d combase!CRpcChannelBuffer::SendReceive2+0x64b [d:\9147\com\combase\dcomrem\channelb.cxx:4796], calling combase!MTAThreadDispatchCrossApartmentCall [d:\9147\com\combase\dcomrem\chancont.cxx:156]
0000009549e4e2b0 00007ff88e1bb6f7 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
...
0000009549e4f5d0 00007ff8827d79cd clr!ManagedThreadBase_DispatchOuter+0x75, calling clr!ManagedThreadBase_DispatchMiddle
0000009549e4f5e0 00007ff8828601af clr!EEConfig::GetConfigDWORD_DontUse_+0x3b, calling clr!EEConfig::GetConfiguration_DontUse_
0000009549e4f660 00007ff8828574fa clr!FinalizerThread::FinalizerThreadStart+0x10a, calling clr!ManagedThreadBase_DispatchOuter
0000009549e4f6a0 00007ff8827d55b9 clr!EEHeapFreeInProcessHeap+0x45, calling kernel32!HeapFreeStub
0000009549e4f700 00007ff882882e8f clr!Thread::intermediateThreadProc+0x86
0000009549e4f780 00007ff882882e6f clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk
0000009549e4f7c0 00007ff88dcd13d2 kernel32!BaseThreadInitThunk+0x22
0000009549e4f7f0 00007ff88e2003c4 ntdll!RtlUserThreadStart+0x34

从堆栈信息看,原来是终结器线程卡死了,从 MTAThreadDispatchCrossApartmentCall 方法看,貌似是 MTASTA 做了一个调用,到这里有经验的朋友应该知道,这和 com 组件有关系了,也就是说 Finalizer 线程无法释放由 STA 线程创建的 COM 对象,那到底是哪一个线程创建了没有被合理释放的 COM 组件呢?

4. 寻找创建 COM 组件的线程

说实话,这个对COM组件不了解的话,很难找出答案,但天无绝人之路,当我回头看 线程列表 的时候,发现居然有 38 个 STA线程,截图如下:

这里面肯定有问题,接下来抽一个线程看看调用栈如何。


0:004> !clrstack
OS Thread Id: 0x41cb4 (4)
Child SP IP Call Site
000000954da1ee38 00007ff88e220c8a [HelperMethodFrame: 000000954da1ee38] System.Threading.Thread.SleepInternal(Int32)
000000954da1ef30 00007ff88138c20a *** WARNING: Unable to verify checksum for mscorlib.ni.dll
System.Threading.Thread.Sleep(Int32)
000000954da1ef60 00007ff82322437f xxx.CFileLogTask.DoWork()
000000954da1f160 00007ff8232234d6 xxx.CTask.InitStart()
000000954da1f240 00007ff8813c31d3 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000954da1f310 00007ff8813c3064 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000954da1f340 00007ff8813c3032 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
000000954da1f390 00007ff8813bc812 System.Threading.ThreadHelper.ThreadStart()
000000954da1f5e8 00007ff8827d6bb3 [GCFrame: 000000954da1f5e8]
000000954da1f938 00007ff8827d6bb3 [DebuggerU2MCatchHandlerFrame: 000000954da1f938]

接下来反编译下 xxx.CFileLogTask.DoWork() 方法看看它是如何被 Thread 执行的。

到这里终于水落石出,罪魁祸首在 CurrThread.SetApartmentState(ApartmentState.STA); 这一句上,我也不知道为啥开个 Thread 还要给个 STA。。。

三:总结

本次事故主要是因为在 STA 线程上用到了 COM 组件,导致让 MTA 模型的 Finalizer 线程去释放时被卡死,而这个Thread又没有用 Application.Run 启动消息循环,STA也是 Sleep 状态,我个人感觉两者无法通讯,给到朋友的建议是去掉 Thread 的 STA。

其实这里有一个很好的点就是,当内存暴涨,不一定是 生产端 的问题,也有可能是 消费端

记一次 .NET 某消防物联网 后台服务 内存泄漏分析的更多相关文章

  1. 记一次 .NET 某HIS系统后端服务 内存泄漏分析

    一:背景 1. 讲故事 前天那位 his 老哥又来找我了,上次因为CPU爆高的问题我给解决了,看样子对我挺信任的,这次另一个程序又遇到内存泄漏,希望我帮忙诊断下. 其实这位老哥技术还是很不错的,他既然 ...

  2. 记一次 .NET 某智能交通后台服务 CPU爆高分析

    一:背景 1. 讲故事 前天有位朋友加微信求助他的程序出现了CPU爆高的问题,开局就是一个红包,把我吓懵了! 由于是南方小年,我在老家张罗处理起来不方便,没有第一时间帮他处理,朋友在第二天上午已经找出 ...

  3. 记一次 .NET 某招聘网后端服务 内存暴涨分析

    一:背景 1. 讲故事 前段时间有位朋友wx找到我,说他的程序存在内存阶段性暴涨,寻求如何解决,和朋友沟通下来,他的内存平时大概是5G 左右,在某些时点附近会暴涨到 10G+, 画个图大概就是这样. ...

  4. 记一次 .NET 某物管后台服务 卡死分析

    一:背景 1. 讲故事 这几个月经常被朋友问,为什么不更新这个系列了,哈哈,确实停了好久,主要还是打基础去了,分析 dump 的能力不在于会灵活使用 windbg,而是对底层知识有一个深厚的理解,比如 ...

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

    一:背景 1. 讲故事 我在年前写过一篇关于CPU爆高的分析文章 再记一次 应用服务器 CPU 暴高事故分析 ,当时是给同济做项目升级,看过那篇文章的朋友应该知道,最后的结论是运维人员错误的将 IIS ...

  6. 记一次 .NET 某外贸Web站 内存泄漏分析

    一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了 ...

  7. 记一次 .NET 某三甲医院HIS系统 内存暴涨分析

    一:背景 1. 讲故事 前几天有位朋友加wx说他的程序遭遇了内存暴涨,求助如何分析? 和这位朋友聊下来,这个dump也是取自一个HIS系统,如朋友所说我这真的是和医院杠上了,这样也好,给自己攒点资源, ...

  8. 记一次 .NET 某智慧水厂API 非托管内存泄漏分析

    一:背景 1. 讲故事 七月底的时候有位朋友在wx上找到我,说他的程序内存占用8G,托管才占用1.5G,询问剩下的内存哪里去了?截图如下: 从求助内容看,这位朋友真的太客气了,动不动就谈钱,真伤感情, ...

  9. 记一次 .NET 某WMS仓储打单系统 内存暴涨分析

    一:背景 1. 讲故事 七月中旬有一位朋友加wx求助,他的程序在生产上跑着跑着内存就飙起来了,貌似没有回头的趋势,询问如何解决,截图如下: 和这位朋友聊下来,感觉像是自己在小县城当了个小老板,规律的生 ...

随机推荐

  1. Python语法之基本数据类型

    一.数据类型之字符串str 作用:主要用于记录描述性性质的数据,如姓名.地址.邮箱: 定义: 方式1 # 单引号 name = 'jason' 方式2 # 双引号 name = "jason ...

  2. 显卡不是你学习 Deep Learning 的借口

    显卡不是你学习 Deep Learning 的借口 很多人在学习深度学习的时候会以自己没有 RTX N 卡的理由不动手实操,只满足于看看"娱乐"视频,听几节基础知识.当然,如果只是 ...

  3. 1、学习算法和刷题的框架思维——Go版

    前情提示:Go语言学习者.本文参考https://labuladong.gitee.io/algo,代码自己参考抒写,若有不妥之处,感谢指正 关于golang算法文章,为了便于下载和整理,都已开源放在 ...

  4. java 图形化小工具Abstract Window Toolit 菜单项

    AWT 中的菜单由如下几个类组合而成 MenuBar: 菜单条,菜单的容器. Menu: 菜单组件,菜单项的容器,它也是Menultem的子类,所以可作为菜单项使用. PopupMenu: 上下文菜单 ...

  5. 以太网/ IPV4/IPV6包头,TCP包头格式回顾

    问题:以太网数据包,承载的数据内容大小46~1500字节,是如何来的? 以太网数据包结构  以太网协议规定最小链路层数据包(帧)为64字节,其中以太网首部+尾部共计18字节(源/目的MAC12字节:上 ...

  6. 通过go调用bat解决乱码核心代码

    背景:通过go写的程序调用dos命令(如dir c:),返回值往往有中文,默认会出现乱码. 解决:转码. 代码:GO package shellLib import ( "golang.or ...

  7. layui踩过的坑

    layui 表格合计行取整 原代码:(文件位置:..\layui\lay\modules\table.js) var e=o.totalRowText||"",i=parseFlo ...

  8. MyBatis学习(三)MyBatis基于动态代理方式的增删改查

    1.前言 上一期讲到MyBatis-Statement版本的增删改查.可以发现.这种代码写下来冗余的地方特别多.写一套没啥.如果涉及到多表多查询的时候就容易出现问题.故.官方推荐了一种方法.即MyBa ...

  9. JAVA通过正则匹配html里面body标签的内容,去掉body标签

    /** * 获取html中body的内容 包含body标签 * @param htmlStr html代码 * @return */ public static String getBody(Stri ...

  10. 平衡二叉树(c++)实现(存在问题:插入节点后,问题:调整树的结构存在问题)

    !!版权声明:本文为博主原创文章,版权归原文作者和博客园共有,谢绝任何形式的 转载!! 作者:mohist 更新那时间: 22:13  03-02-2020  逻辑存在问题:插入节点后,调整数的结构不 ...