ZLBH内存调试Word文档下载推荐.docx

ZLBH内存调试Word文档下载推荐.docx

《ZLBH内存调试Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《ZLBH内存调试Word文档下载推荐.docx（24页珍藏版）》请在冰豆网上搜索。

6.实践方案，进行调整及优化实验，对方案进行调整；

3.准备与执行

在执行任务并实施初步计划时，因为考虑到自己对.NET内存管理原理和机制有一定的了解，系统渐入型的学习并不如实际操练，在操作过程中进行有针对性的学习更有效，效率更高，正所谓“LeaningSwiminSwimming（在游泳中学习游泳）“;

跳过计划的第一步，直接进入第二步：

.NET内存分析工具学习及运用；

.NET的内存分析工具的产品很多，有专业公司的，也有各大IT厂商的，比如Intel的Vtune,HP的DebugDiagnosticsTool，微软的老牌工具Windbg，究其根本原理大同而小异，我将其归纳为两类：

1.内存镜像分析工具

主要特点是通过抓取运行程序的内存快照镜像（MemoryDump），生成磁盘文件，然后通过对存快照镜像文件进行分析，其中以Microsoft的Windbg为代表

2.内存探测工具（Profiler）

主要特点是通过Profiler加载要调试程序，监控探测目标程序的内存活动，包括方法，对象，对象关系等，显示结果的很直观，类似于性能计数器（PerfomanceCounter），并可以通过SnapShot（快照）功能获取某个时间点的内存镜像，并可以对多个SnapShot进行比较，其中以RedGate的ANTSMemoryProfiler为代表。

两种内存分析工具各有利弊，内存镜像分析工具的优点是不通过加载目标程序的方式进行调试，减少了分析的干扰因素，缺点是不能实时图形化，表格化的查看内存的使用情况，而且分析主要是通过命令行命令的方式进行调试，功能强大但复杂,分析内存只是工具的一部分功能。

内存探测工具的优缺点则正好相反。

在.NET内存分析工具学习及运用的过程中，比较了以下几种内存分析工具,列表如下:

名称

内存

镜像

实时

调试

图表化

源代码

VS

集成

.NET优化

附加

进程

MicrosoftWindbg6.7

ANTsMemoryProfiler5

Intel 

VTune 

性能分析器

AutomatedQAAQTime

DebugDiagnosticsTool

SciTech.NetMemProfiler3.5

注释：

内存镜像:

直接导入MemeoryDump文件进行分析

实时调试:

实时跟踪内存中的对象活动状态

图表化:

是否使用图形及列表方式显示对象信息

源代码调试:

是否可以加载源代码文件进行跟踪调试

VS集成:

是否可以作为插件在VS工程中使用

.NET优化:

是否专门对.net托管代码进行优化

附加进程:

是否可以通过AttachProcess的方式进行调试

根据上表的对比，初步选择Windbg+DebugDiagnosticsTools+.NetMemProfiler三个工具结合使用，主要原因如下：

Windbg：

微软官方提供的老牌调试工具，不仅能够通过内存镜像调试内存还能调试线程，CPU，通过外部扩展SoS.dll（SonofStrick）和psscor2可以调试.net非托管代码；

DebugDiagnosticsTools:

HP提供的调试工具，主要的特点是可以直接通过内置的进程监控器抓取内存镜像、根据特定脚本监视进程的内存泄漏情况、通过分析脚本自动生成Crash/Hang及MemoryPressureAnalyzer分析报告。

.NetMemProfiler：

专门针对于.NET程序，功能最全的内存分析工具，最大的特点是具有内存动态分析（AutomaticMemoryAnalysis）功能。

不管工具如何强大，工具主要做的工作还是指标的收集，最终还是需要通过人工去对收集的信息进行分析。

软件中一般会给出如下指标：

指标名称

注释

备注

FreeMemory

空闲内存，没有被分配，当前可用内存

ReservedMemory

保留内存，指被请求但是没有被实际分配的内存

CommittedMemory

已提交内存，实际被程序使用的内存

TotalMemory

虚拟内存空间（32位机是2GB的用户模式内存空间，在64位机上是4GB）

VirtualAllocation

虚拟分配内存，程序大部分的内存所在，VA是dotNet对象存放的位置

又称RegionUsageIsVAD

MappedMemory

文件映射内存，属于VirtualAllocation的一部分，表示外部文件映射到内存占用的部分

又称MEM_MAPPED

LoadedModules

加载模块内存

表示一个可执行的映射文件的一部分映射到内存，就是dll或一个exe的内存映射

又称MEM_IMAGE

Threads

线程内存

NativeHeaps

非托管堆内存

又称RegionUsageHeap

一般内存的使用可以通过几种方式进行统计，例如在Windbg中，输入！

address–summary得到内存镜像中的内存分配情况一览，输出结果分为三个部分：

“UsageSUMMARY”（按使用情况分类）、“TypeSUMMARY（按类型分类）“、”StateSUMMARY（按状态分类）“；

可以从上图看出，目前程序使用的内存（Busy）为1G，这个数字和我们从任务管理器中看到的300多M相差甚远，这个数字可以通过DebugDiagnosticsTools的进程监控工具得到印证，如下图：

进一步通过DebugDiagnosticsTools的”AdvancedAnalysis”的内存压力分析功能的到内存压力测试报表文件。

虚拟内存总览，总内存为2G,空闲内存是1G,2G-1G=1G,得到ZLBH程序运行使用字节数为1G。

VAD分配内存，其中保留内存37.40M，已提交内存430M，另外文件映射内存为219M，这里可以看到文件映射占到了已提交内存的一半作用，过于庞大。

程序加载的Dll和Exe共225个，占用内存206.27M

NativeHeap非托管堆共有21个，保留内存有241.67M，已提交内存为43.89M。

其中msvcr80.dll占用最多，保留内存就占用了127M，而且可以看到堆上的碎片达到了47.79%.

针对多个样本进行初步分析，从指标数据得到初步结论是：

1、ZLBH整体内存消耗普遍在600M以上，程序实际占用的内存在300M左右即MEM_PRIVATE；

2、ZLBH加载DLL内存占用在150M-200M之间，加载Dll个数在150个以上；

3、ZLBH文件映射内存MappedMemory在80M以上，最高200多M；

4、非托管堆在240M以上，堆数量在21个以上；

得出的初步结论只是现象，还不能通过现象得到ZLBH内存占用的实质，因为还有几个问题有待弄清楚：

1、是哪些.Net对象占用了内存，是否合理？

2、托管堆上的内存是由哪些托管对象占用的，是否合理？

3、映射内存是被哪些外部对象占用了，是否合理？

4、是否有托管资源没有被回收?

5、是否有非托管资源没有被释放？

6、什么原因会造成了内存碎片，内存碎片是否会造成性能问题？

前几个问题是纯粹的查询分析问题，是下一步工作的重点，通过内存跟踪工具可以得到结果。

最后一个问题则是一个理论性的问题，是定位问题的基础，同时还必须有对问题分析的衡量标准；

一般发现和纠正的应用程序内存问题时，首先考虑的是内存占用、垃圾回收没有快速清理对象方面的问题，但是内存碎片也是影响应用程序内存占用的一个重要方面，如果应用程序堆上的内存碎片过多，会导致应用程序进程消耗大量的虚拟内存空间，通常非托管堆会经常出现内存碎片的情况，虽然.NETFramework在内存管理上对内存碎片的产生做了一些特殊的处理，但是也有可能会出现这种情况，产生内存碎片的常见情况有：

●总是加载和卸载小的的程序集

●由于COM操作而加载大量的COMDLL

●在托管堆中同时加载程序集和COMDLL

●托管对象被钉住造成大量的内存碎片

4.分析

在上节中就软件提供的指标现象，提出了几个问题，现在就其为线索来分析

●是哪些.Net对象占用了内存，是否合理？

通过.netMemoryProfiler导入MemoryDump文件，收集InstanceData（实例数据），总共有1,052,419个活动实例，共使用字节数为81,718,640Bytes（约81MB）。

按字节数排序如下图：

可以看到占用内存最多的前四位按类型排序分别为String、Byte[]、Int32[]、String[];

占用内存大小分别为：

●String:

29M;

平均实例占用85Byte；

●Byte[]:

11M;

平均实例占用437Byte;

●Int32[]:

5M;

平均实例占用409Byte;

●String[]:

2.9M;

平均实例占用41Byte;

继续查看类型实例明细，排序得到使用内存最多的实例，并抽取实例明细得到实例引用关系，例如：

得到占用内存做多的String实例，实例号为#1046245,占用内存327K，得到实例引用关系

对应的是表达式ID数组，程序中对应的是Dictionary<

string,string[]>

_expIDMappingInfo4Client。

从上图可以看到引用的根是ExpressionEngine是唯一实例；

这样被ExpressionEngine引用的字符串内容占到收集的2000个实例样本的80%左右；

再来看Byte[]类型的实例，查询实例信息，按实例频率区分主要占用有如下几个地方

●LumiSoft.Net.Mime.MimeEntity.m_Encoded