为什么机器上没有分页内存时Process.PagedMemorySize64 > 0？答案

【问题标题】：Why is Process.PagedMemorySize64 > 0 when there is no paging memory on the machine?为什么机器上没有分页内存时Process.PagedMemorySize64 > 0？
【发布时间】：2010-02-16 20:21:45
【问题描述】：

我在页面文件大小设置为零的机器上运行 .net 代码。我的应用程序记录 System.Diagnostics.Process.PagedMemorySize64 并显示值 > 0。

这怎么可能？

PagedMemorySize64 的文档内容如下：

该属性返回的值表示进程使用的虚拟内存分页文件中的当前内存大小。

我错过了什么？

背景：
我这样做是为了确定我是否有内存泄漏。我使用的配置文件没有显示任何增长，但 System.Diagnostics.Process 的内存值继续增加。

我认为我可能正在处理大对象堆碎片。我的程序正在显示大图像的 WPF 幻灯片放映，图像之间带有淡入淡出动画。

欢迎任何解释。

谢谢。

【问题讨论】：

标签： .net memory-management memory-leaks large-object-heap

【解决方案1】：

我认为该描述具有误导性。实际上，进程中的所有虚拟内存页面都是可分页的。但它们不一定会出现在页面文件中。从 DLL 加载的任何代码都不必存储在那里。内存管理器在需要空间时简单地丢弃页面，在需要换回时从 DLL 重新加载。

在 .NET 进程中，这至少是为 CLR、JIT 编译器和任何 Ngen-ed 程序集的代码映射的页面。所有 .NET 框架程序集都是 Ngen-ed。页面文件将用于其余部分，任何 JIT 编译的代码和数据。

这个数字对诊断泄漏没有帮助。它不断变化，没有什么可以让内存管理器直接决定换出一个页面。除了最小化程序的主窗口之外，它还会触发内存管理器积极修剪工作集（= 驻留在 RAM 中的页面数）。获得一个好的内存分析器以取得成功。

【讨论】：

我实际上将 PeakVirtualMemorySize64 的趋势视为可能的泄漏迹象。我想不出峰值会随着时间的推移继续增加的任何原因。
检测内存泄漏总是很简单：您的程序最终会因 OutOfMemory 异常而崩溃。如果没有，那么您就没有泄漏。
在这种特殊情况下，我因内存相关的直接显示错误而崩溃。我正在尝试检测和隔离泄漏，而无需让某些东西运行数周直到内存不足。此应用程序需要连续数周 24x7 运行。