【发布时间】:2015-06-08 15:54:08
【问题描述】:
在检查崩溃转储文件以查找客户端报告的内存不足异常时,!DumpHeap -stat 的结果显示,45,000 个“免费”类型的对象占用了 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)。对我来说,这排除了由固定引起的空闲块。
我还检查了空闲块本身,看看它们是否具有一致的大小,但经过检查,大小差异很大,从不到 5MB 到只有大约 12 个字节左右。
任何帮助将不胜感激!我不知所措,因为存在碎片,但没有迹象表明它是由我知道要查看的两个地方引起的,即大对象堆 (LOH) 和固定句柄。
【问题讨论】:
-
做一个 !address –summary 以获得您的进程的概述,注意堆使用情况(这是本机堆),以防您有本机泄漏。如果您需要更多帮助,请使用结果更新您的帖子。
-
@KjellGunnar - !address -summary 的输出显示只有 146MB 用于本机堆。大部分在
部分,应该主要是与 CLR 相关的项目,其中大部分来自 575MB 的免费对象。 -
265 实际上是相当多的固定句柄。碎片是累积的,所以在许多有大约 265 个固定句柄的 GC 上,它会加起来。
-
@SteveJohnson - 你确定这是关于固定句柄碎片累积的真实情况。我正在阅读OutOfMemoryException and Pinning,它说第 0、1 和 2 代应该在可能的情况下进行压缩,所以这不会消除固定句柄造成累积碎片影响的可能性吗?
标签: memory-leaks out-of-memory clr windbg memory-fragmentation