.net CPU和内存爆高的分析与处理01

一、问题现象


从截图现象看,应用程序CPU和内存都上去了。并且还是导致程序崩溃了。这时我想到了在老师(一线码农)那里学到的分析办法,先抓取一个Dump。然后仔细分析。

二、分析Dump

通过Address -summary命令,查看内存确实偏高,并且都在托管堆中。

2.1 确认CPU是否真的存在跑高的的现象

通过!tp 查看CPU 确实偏高

三、分析内存泄漏问题

3.1 通过!dumpheap -stat 命令,看看内存中对象分配情况


从上图,不难看出Seismic.Core.TraceData的数量挺多的,837 546 144(8亿多个对象),有点恐怖。

3.2 查找Seismic.Core.TraceData对象的持有者

通过dumobj命令,可以看到对象的字段信息,是一个时间和一个浮点数。

3.3. 然后通过 !gcroot命令,查看对象的引用链


发现此对象被 "4B5C"线程持有,并且在做Clone处理

3.4 找到对应Dll的相关方法


发现在进行对象的深度复制。看上去代码也没什么问题。但和同事一沟通,他将传感器采集到最近25分钟数据,都进行了一个Clone。这么说一还可能就是问题了。我们传感器平均1秒钟4000条数据,25分钟有高达600W条数据,再对600W的对象进行一个深度复制,就将产生1200W的对象。可想内存开销还是可观的。由于外层逻辑也是定时分析,分析完成后也没有进行GC的清理。程序运行时长了,内存就上去了。

四、分析Cpu占用高的情况

4.1 通过!t -special 命令,查看是否存在GC加收的情况

4.2 转换到2b04线程,查看调用栈


从上述调用栈可以看出来,在进行反序列化的时候,触发的GC回收。

4.3 通过syncblk,查看是否存在锁的情况


从上述信息可以看出,当前存在一个锁。

也可以看出,正常在等等GC回收的完成。GC算是CPU密集信息操作,又回收大量数据,CPU上去也算是正常。

五、总结

1 小对象,数量多的情况下,进行深度复制,会导致内存爆高
2 GC在回收大量对象时,会导致CPU爆高

posted @ 2024-02-05 16:47  小龙女先生  阅读(232)  评论(0编辑  收藏  举报