为什么大对象堆大部分是空的？
为什么.NET内存管理会创建如此大的对象堆？大部分看起来都是空的。这是值得担心的事情吗？
以下数据是否意味着实际上我的应用程序中只有 179 MB 的大型对象？ 179 MB 是通过从 1171428792（Heap0 LOH）减去 983396616（空闲 LOH）得到的。
以下信息是通过在 w3wp.exe（即 ASP.NET 进程）上创建的转储文件上使用 WinDbg 收集的。该进程托管在 Windows 2008 64 位操作系统上。该应用程序是使用 Microsoft .NET Framework 4.0 和 ASP.NET MVC 3 构建的。
0:025> !HeapStat
Heap Gen0 Gen1 Gen2 LOH
Heap0 4628496 3840808 319586376 1171428792
Free space: Percentage
Heap0 24 24 1926224 983396616SOH: 0% LOH: 83%
Why does .NET memory management create such a large object heap? Most of it seems to be empty. Is this something to be concerned about?
Does the below data mean that in reality I only 179 MB worth of large objects in my application? 179 MB is arrived at by subtracting 983396616 (free LOH) from 1171428792 (Heap0 LOH).
The below info was collected by using WinDbg on a dump file created on a w3wp.exe i.e. ASP.NET process. The process is hosted on a Windows 2008 64-bit operating system. The application is built using Microsoft .NET Framework 4.0 and ASP.NET MVC 3.
0:025> !HeapStat
Heap Gen0 Gen1 Gen2 LOH
Heap0 4628496 3840808 319586376 1171428792
Free space: Percentage
Heap0 24 24 1926224 983396616SOH: 0% LOH: 83%
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议运行 !DumpHeap -stat
查找名为“FREE”的对象的总字节值。这些将是 LOH 中可供使用的空闲块，但已因大型对象堆的颠簸而变得碎片化。如果这个数字很接近，那么您将使用大量短暂的对象来达到 LOH，并留下可用内存碎片（请记住，该堆永远不会自行压缩）。
I would suggest running a !DumpHeap -stat
Look for the total bytes value for objects named "FREE". These will be free block in the LOH at are available for use, but have been fragmented by thrashing the Large Object Heap. If this number comes close, then you're hitting your LOH with alot of objects that are short lived, and leaving fragments of free memory (remember this heap never compacts itself).
您确定大部分 LOH 已被提交——还是只是保留的地址空间？
我刚刚使用 Sysinternal 的 VM 映射查看了一个 PowerShell.exe 实例。这显示总 GC 堆约为 390MB，但保留了两个最大的块（~240MB 和~125MB）。提交的空间少于 20MB（即分配的物理内存或页面文件空间）。
为了重新执行此操作，总进程提交约为 200MB，小于分配给 GC 堆的地址空间。
Are you sure much of the LOH has been committed – or is it just reserved address space?
I've just looked at a PowerShell.exe instance here with Sysinternal's VM Map. This shows a total GC heap of ~390MB, but the two largest blocks (~240MB and ~125MB) are reserved. Less than 20MB is committed (ie. physical memory or page file space allocated).
To re-enforce this the total process commit is ~200MB, less than the address space allocated to the GC heaps.