工具分析进程中加载​​本机DLL和组件的内存占用？ [英] Tools to analyzing the memory footprint of native DLLs and assemblies loaded in a process?

问题描述

我要根据进程持有的内存130MB，根据任务管理器，用活.NET对象只有11MB dotTrace 所以我想知道发生了什么与其他120MB ??

我需要一个工具列出在一个进程中加载​​组件和机DLL，获取处理中的图像的大小，并且，对于每个组件，测量的JIT编译方法的内存占用量。

listdlls的从SysInternal部分做这项工作。不过，这并不衡量JIT编译code尺寸，它只是提供了原始数据。理想情况下，我想一个用户界面来分析和总结了对这些数据的。

近日，在Visual Studio团队报告说，已经做了这样的分析工具<一href="http://blogs.msdn.com/b/vancem/archive/2011/12/28/publication-of-the-perfview-performance-analysis-tool.aspx"相对=nofollow> PerfView 。这是在博客文章<一说href="http://blogs.msdn.com/b/visualstudio/archive/2012/03/05/visual-studio-11-beta-performance-part-1.aspx"相对=nofollow>的Visual Studio 11 Beta版性能零件编号1 ，部分：的最大VM消费者 - 的DLL 的。是否有人有经验和反馈分析本机DLL和组件封装与PerfView？

除了 listdlls的和 PerfView 的，你会建议任何其他工具？

---

好了，的VMMap 通过建议的西蒙Mourier 的似乎是更适合的工具，这个任务。 的VMMap显示大部分工作集内存进入托管堆栈（113MB下面绿色） ，所以问题更多的是比非托管内存.NET对象。绿色锯齿形曲线，只是加载/卸载会议的时间表。出于某些原因，我的第一个措施是非常错误的：

• dotTrace告诉我，我有.NET对象的41MB分配，
• WMMAP显示180MB的一个工作组（任务管理器显示了类似的数字）
• WMMAP显示了由GC分配托管堆上的113MB。这90MB托管堆内存是在工作组：

所以，我的计划是：

1. 确定为什么GC分配托管堆的113MB的.NET对象的41MB？ （是这样的数字是否正常？是由于高不成？）
2. 在缩小这个41MB的.NET对象的工作分配！

解决方案

既然你提到的Sysinternalslistdlls的，有一个名为的 Process Explorer的有大量信息，比listdlls的（你要确保你有最新的版本也有很多的.NET信息得多好，支持64比特和32位进程，等等）。

对于每一个过程中，你可以有非托管内存同步的意见（专用字节等）和管理内存（GC集合，大对象堆等）显示在列或每个进程。

从Sysinternals的另一个很酷的工具是的VMMap 。这是一个进程的内存分析工具，并显示不同类型的虚拟和物理内存类型的分类。

至于你120MB的问题，你真的要检查注入在过程中并没有标准的Windows安装或标准DLL一整套流程的一部分，所有的非托管的DLL。对于这样大尺寸的分配，我会先跟踪过程中的图形组件，因为它们是特别出名的内存分配大块（特别是如果你谈论一个工具，如NDepend的其中的是的图形）。进程资源管理器也可以跟踪GDI和用户对象的数量。

在GDI的话题，有一个名为 GDIView 可以在这里免费的工具，让GDI的详细信息，每个进程对象分配。

I have a process holding 130MB of memory according to task manager, with only 11MB of live .NET objects according to dotTrace so I am wondering what's happening with the other 120MB??

I'd need a tool to list assemblies and native DLLs loaded in a process, gets the size of the images in process, and, for each assembly, measure the memory footprint of the methods JITed.

ListDlls from SysInternal does partly that job. But it doesn't measure JITed code size and it just provides raw data. Ideally I'd like a UI to analyze and sum-up these data.

Recently, the Visual Studio team reported having done such analysis with the tool PerfView. This is stated in the blog post Visual Studio 11 Beta Performance Part #1, section: The Biggest VM Consumer - DLLs. Does someone has experience and feedback analyzing native Dlls and assemblies footprint with PerfView?

Except ListDlls and PerfView, would you recommend any other tool?

---

Ok, VMMAP advised by Simon Mourier seems to be the more suited tool for this task. VMMAP shows that the bulk of working set memory goes into the Managed Stack (113MB in green below), so the problem is more related to .NET objects than unmanaged memory. The green saw tooth curve, is just a timeline of loading/unloading sessions. For some reasons, my first measures were quite wrong:

• dotTrace tells me I have 41MB of .NET objects allocated,
• WMMAP shows a working set of 180MB (task manager shows a similar number)
• WMMAP shows 113MB of managed heap allocated by the GC. 90MB of this managed heap memory is in the working set:

So my plan is:

1. Identify why the GC allocates 113MB of managed heap for 41MB of .NET objects? (are such numbers normal? is it due to high fragmentation?)
2. Work on shrinking this 41MB set of .NET objects allocated!

解决方案

Since you mention sysinternals' ListDlls, there is another tool called Process Explorer that has tons of information, and is much much better than ListDlls (you want to make sure you have the latest versions that also has a lot of .NET information, supports 64-bit and 32-bit processes, etc.).

For each process, you can have a simultaneous views of unmanaged memory (private bytes et al.) and managed memory (GC collections, large object heap, etc.) displayed in columns or per process.

Another cool tool from sysinternals is VMMAP. It's a process memory analysis utility and shows a breakdown of different types of virtual and physical memory types.

As for you 120Mb question, you really want to check all unmanaged DLLs that are injected in your process and are not part of standard Windows installation or standard DLL set of processes. For such big size allocations, I would first track graphical components of course as they are notably known for allocation big chunks of memory (especially if you speak about a tool such as NDepend which is graphical). Process Explorer can also tracks the number of GDI and USER objects.

On the GDI topic, there is a free tool named GDIView available here that gives a details of GDI objects allocated per process.

这篇关于工具分析进程中加载​​本机DLL和组件的内存占用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！