我们有兴趣改进总大小和私人工作集(pws).在这个问题上,我只想看看pws. VMMap通常报告一个105 mb的pws.这11MB是图像,31mb是堆,52 mb是托管堆,7 mb是私有数据,其余是堆栈,页表等.
这里的最大奖是托管堆.我们可以直接在我们自己的代码(即我们创建和管理的对象和窗口)中占用约8mb的堆放堆.其余的是由我们使用的框架的元素创建的可能的.NET对象.
我们想要做的是确定框架帐户的哪些元素,这些用法的一部分可能会重建我们的系统,以避免在可能的情况下使用它们.任何人都可以建议如何进行这项调查？
进一步澄清：
目前为止,我已经使用了一些工具,包括优秀的ANTS Profilers和WinDbg与SOS,他们允许我看到托管堆中的对象,但这里真正的兴趣不是“什么？”,而是为什么？ “理想情况下,我想说可以这样说：“因为我们使用WCF,所以在这里创建了10万个对象,如果我们编写自己的本地运输,那么我们可以节省8MB的x品质风险和开发工作.”
在300,000个对象上执行gcroot是不可能的.
解决方法
运行应用程序后,您可以附加WinDbg并浏览托管堆. (或者您可以进行内存转储并离线浏览).它将能够很快地告诉您消耗最大内存量的对象类型.
首先,您将需要加载启用托管应用程序调试的SOS扩展：
.loadby sos mscorwks
然后,您可以使用！dumpheap获取堆信息,-stat开关给出分配哪些类型的整体堆信息：
!dumpheap -stat
-type参数给出了指定类型的分配实例的特定信息：
!dumpheap -type System.String
有一些其他的命令,你可能会发现如下：
>！gcroot – 跟踪分配的对象备份它的根找到为什么它在内存中.
>！dumpobj – 转储一个特定的对象,以便您可以看到它的内容.
>！EEHeap – 给出一些一般的堆数据.
MSDN有一个full list of SOS commands及其交换机.
WinDbg是一个非常复杂的工具,但是如果您搜索帮助您开始使用,则会有许多在线教程和指南.或者,我可以推荐John Robbins的这本书Debugging Microsoft .NET 2.0 Applications,该书在WinDbg和SOS的.net调试功能中有一些很好的细节.
您可以将SOS扩展加载到visual studio中,而不是将其输入到即时窗口中,那么您应该可以直接在VS立即窗口中使用SOS命令：
.load SOS.dll
您也可能会发现CLR Profiler和Usage guide有帮助.