gpt4 book ai didi

memory-leaks - 故障转储中过多的第 2 代空闲 block

转载 作者:行者123 更新时间:2023-12-04 18:04:26 47 4
gpt4 key购买 nike

在检查故障转储文件是否存在客户端报告的内存不足异常时,!DumpHeap -stat 的结果显示 45,000 个“Free”类型的对象占用了 575MB 的内存由于大小原因,我认为其中大部分必须驻留在第 2 代中。

我首先查找问题的地方是大对象堆 (LOH) 和固定对象。包含可用空间的大对象堆只有 70MB,所以这不是问题,运行 !gchandles 显示:

GC Handle Statistics:
Strong Handles: 155
Pinned Handles: 265
Async Pinned Handles: 8
Ref Count Handles: 163
Weak Long Handles: 0
Weak Short Handles: 0
Other Handles: 0

与空闲对象的数量 (45,000) 相比,句柄数量非常少(大约 600 个)。对我来说,这排除了由固定引起的空闲 block 。

我还查看了空闲 block 本身,看它们是否具有一致的大小,但在检查时大小变化很大,从不到 5MB 到只有大约 12 字节左右。

任何帮助将不胜感激!我不知所措,因为存在碎片,但没有迹象表明它是由我知道要查看的两个地方引起的,这两个地方是大对象堆 (LOH) 和固定句柄。

最佳答案

自由对象在哪一代?

I assume would have to reside in Gen 2 due to the size

大小与世代无关。要找出空闲 block 位于哪一代,您可以按照以下步骤操作:

!dumpheap -stat -type Free 获取方法表:

0:003> !dumpheap -stat -type Free
total 7 objects
Statistics:
MT Count TotalSize Class Name
00723538 7 100 Free
Total 7 objects

!eeheap -gc,获取各代的起始地址。

0:003> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x026a1018
generation 1 starts at 0x026a100c
generation 2 starts at 0x026a1000
ephemeral segment allocation context: none
segment begin allocated size
026a0000 026a1000 02731ff4 0x00090ff4(593908)
Large object heap starts at 0x036a1000
segment begin allocated size
036a0000 036a1000 036a3250 0x00002250(8784)
Total Size 0x93244(602692)
------------------------------
GC Heap Size 0x93244(602692)

然后通过传递开始和结束地址(例如此处的第 2 代)仅转储特定代的空闲对象:

0:003> !dumpheap -mt 00723538 0x026a1000 0x026a100c
Address MT Size
026a1000 00723538 12 Free
026a100c 00723538 12 Free
total 2 objects
Statistics:
MT Count TotalSize Class Name
00723538 2 24 Free
Total 2 objects

所以在我的简单情况下,第 2 代中有 2 个空闲对象。

固定 handle

600 个固定对象不应导致 45.000 个空闲内存块。仍然根据我的经验,600 个固定 handle 很多。但首先,检查空闲内存块位于哪一代。

关于memory-leaks - 故障转储中过多的第 2 代空闲 block ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29434204/

47 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com