windbg - 为什么 windbg> !EEHeap -gc 显示的托管堆比 VMMAP.exe 小得多？

Question

我有一个 C# 应用程序，它的内存使用量会随着时间的推移而增加。我进行了定期用户模式转储，并在加载 sos 后运行 !EEHeap -gc 来监视托管堆大小。在 windbg/sos 中，我看到它从 ~14MB 开始增长到 160MB，然后缩小到 15MB，但应用程序“私有(private)字节”从未显着减少。我已经确定了导致“专用字节”增加的事件，因此我可以控制何时发生内存增长。

我尝试运行 Vmmap.exe 并注意到它报告了大约 360MB 的托管堆，进行了快速转储并使用 windbg/sos/eeheap -gc 我只看到了 15MB。

为什么我会看到如此不同的值？托管堆真的是 vmmap.exe 报告的内容吗？

我如何检查 windbg 中托管堆的这个区域？

Answer 1

您不能使用 WinDbg 进入 .NET 应用程序，然后同时运行 VMMap。这将导致 VMMap 挂起。也不能反过来:先启动VMMap，然后打入WinDbg，再刷新VMMap中的值。

因此，VMMap 显示的值可能永远不会相等，因为数字来自不同的时间点。不同的时间点也可能意味着垃圾收集器已经运行。如果应用程序变化不大，则值应该接近。

在我的测试中，VMMap 中托管堆的已提交部分是!eeheap -gc 的总和。和 !eeheap -loader ，这听起来很合理。

鉴于 !eeheap -gc 的输出，我们在第 2 代 (11aa0000) 处开始了 GC 堆，其大小仅为 3.6 MB。

Number of GC Heaps: 1
generation 0 starts at 0x0000000011d110f8
generation 1 starts at 0x0000000011cd1130
generation 2 starts at 0x0000000011aa1000
...
GC Heap Size          0x374a00(3623424)

!address给出详细信息:

...
+        0`11aa0000        0`11ef2000        0`00452000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  
         0`11ef2000        0`21aa0000        0`0fbae000 MEM_PRIVATE MEM_RESERVE                                    <unknown>  
         0`21aa0000        0`21ac2000        0`00022000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     <unknown>  
         0`21ac2000        0`29aa0000        0`07fde000 MEM_PRIVATE MEM_RESERVE                                    <unknown>
+        0`29aa0000        0`6ca20000        0`42f80000             MEM_FREE    PAGE_NOACCESS                      Free 
...

虽然没有记录，但我相信一个新的段从 11aa0000 开始，由 + 指示符号。 GC段结束于29aa0000，也是下一段的起点。交叉检查:.NET 内存应报告为 <unknown>在最后一栏 - 好的。

总 GC 大小(保留 + 提交)为

?29aa0000-11aa0000
Evaluate expression: 402653184 = 00000000`18000000

这是 402 MB 或 393.216 kB，在我的例子中非常接近 VMMap 报告的 395.648 kB。

如果你有更多的 GC 堆，整个过程需要更多的努力。因此，我通常会采用快捷方式，如果您知道除了调用 VirtualAlloc() 的 .NET 之外没有其他任何东西，那么这样做是可以的。输入 !address -summary然后看第一个<unknown>条目:

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free                                    144      7ff`d8a09000 (   7.999 Tb)           99.99%
<unknown>                               180        0`1a718000 ( 423.094 Mb)  67.17%    0.01%
...