.net – 分析进程中加载??的本机DLL和程序集的内存占用的工具？

发布时间：2020-12-13 20:08:33 所属栏目：Windows 来源：网络整理

导读：根据任务经理,我有一个拥有130MB内存的进程,根据 dotTrace,只有11MB的活.NET对象,所以我想知道其他的120MB？我需要一个工具来列出加载进程中的程序集和本机DLL,获取正在处理的图像的大小,并为每个程序集测量方法JITed的内存占用. 来自SysInternal的ListDlls

根据任务经理,我有一个拥有130MB内存的进程,根据 dotTrace,只有11MB的活.NET对象,所以我想知道其他的120MB？

我需要一个工具来列出加载进程中的程序集和本机DLL,获取正在处理的图像的大小,并为每个程序集测量方法JITed的内存占用.

来自SysInternal的ListDlls部分是这项工作.但是它不测量JITed代码大小,它只提供原始数据.理想情况下,我想要一个UI来分析和总结这些数据.

最近,Visual Studio团队报告了使用工具PerfView进行了这样的分析.这在博客文章Visual Studio 11 Beta Performance Part #1,部分：最大的虚拟机消费者 – DLLs中已有说明.有人有使用PerfView分析本机Dll和组件足迹的经验和反馈？

除了ListDlls和PerfView,你会推荐任何其他工具吗？

好的,VMMAP Simon Mourier建议似乎是这个任务更适合的工具. VMMAP显示,大部分工作集内存进入托管堆栈(113MB,绿色以下),因此与非托管内存相比,问题更多地与.NET对象相关.绿色锯齿曲线,只是加载/卸载会议的时间表.由于某些原因,我的第一个措施是错误的：

> dotTrace告诉我我分配了41MB的.NET对象,
> WMMAP显示一个180MB的工作集(任务管理器显示类似的数字)
> WMMAP显示由GC分配的113MB的托管堆.该管理堆内存的90MB位于工作集中：

所以我的计划是：

>识别为什么GC为41MB的.NET对象分配113MB的托管堆？ (这样的数字是否正常？是因为高碎片吗？)
>工作缩小这41MB集合的.NET对象分配！

由于你提到了sysinternals的ListDlls,所以还有另一个名为 Process Explorer的工具,它有大量的信息,比ListDlls要好得多(你想确保你有最新的版本,也有很多的.NET信息,位和32位进程等).

对于每个进程,您可以同时查看显示在列或每个进程中的非托管内存(专用字节等)和托管内存(GC集合,大对象堆等).

来自sysinternals的另一个很酷的工具是VMMAP.它是一个进程内存分析实用程序,并显示了不同类型的虚拟和物理内存类型的细目.

至于你120Mb的问题,你真的想检查所有未被管理的DLL注入到你的进程中,而不是标准Windows安装或标准DLL进程集的一部分.对于这样大的大小分配,我将首先跟踪图形组件,因为它们特别为分配大块内存而着名(特别是如果您说的是像NDepend这样的图形工具). Process Explorer还可以跟踪GDI和USER对象的数量.

在GDI主题上,这里有一个名为GDIView的免费工具,它提供了每个进程分配的GDI对象的详细信息.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!