为什么 Process.PagedMemorySize64 > 0 当机器上没有分页内存时？
我正在机器上运行 .net 代码，页面文件大小设置为零。我的应用程序记录 System.Diagnostics.Process.PagedMemorySize64 并显示值 > 0.
怎么会这样呢？
PagedMemorySize64 的文档如下：
该属性返回的值表示进程使用的虚拟内存分页文件中当前的内存大小。
我缺少什么？
背景：
我这样做是为了确定是否存在内存泄漏。我使用的配置文件没有显示任何增长，但 System.Diagnostics.Process 的内存值继续增加。
我认为我可能正在处理大对象堆碎片。我的程序正在显示大图像的 WPF 幻灯片，图像之间带有淡入淡出动画。
欢迎任何解释。
谢谢。
I am runing .net code on a machine with the page file size set to zero. My application logs System.Diagnostics.Process.PagedMemorySize64 and is showing a value > 0.
How can this be?
The documentation for PagedMemorySize64 reads:
The value returned by this property represents the current size of memory in the virtual memory paging file used by the process.
What am I missing?
Background:
I'm doing this trying to determine if I have a memory leak. I'm using a profile that isn't showing any growth, yet the memory values from System.Diagnostics.Process continue to increase.
I think that I may be dealing with Large Object Heap fragmentation. My program is displaying a WPF slide show of large images, with fade animation between the images.
Any explanation welcome.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为描述具有误导性。实际上，进程中的所有虚拟内存页面都是可分页的。但它们不一定最终出现在分页文件中。从 DLL 加载的任何代码不必存储在那里。内存管理器在需要空间时简单地丢弃该页面，在需要换回时从 DLL 重新加载该页面。
在 .NET 进程中，这至少是为 CLR、JIT 编译器的代码映射的页面以及任何 Ngen 编辑的程序集。所有 .NET 框架程序集均经过 Ngen 编译。分页文件将用于其余的任何 JIT 编译的代码和数据。
这个数字对诊断泄漏没有帮助。它不断变化，您无需执行任何操作即可使内存管理器直接决定换出页面。除了最小化程序的主窗口之外，这还会触发内存管理器积极修剪工作集（= RAM 中驻留的页数）。获得一个好的内存分析器以取得成功。
I think the description is misleading. Practically all virtual memory pages in a process are pageable. But they don't necessarily end up in the paging file. Any code that's loaded from DLLs doesn't have to be stored there. The memory manager simply discards the page when it needs room, it reloads it from the DLL when it needs to be swapped back in.
In a .NET process, that will at least be the pages mapped for the code for the CLR, JIT compiler and any Ngen-ed assemblies. All the .NET framework assemblies are Ngen-ed. The paging file will be used for the rest, any JIT-compiled code and data.
This number is not going to be helpful to diagnose leaks. It constantly changes, there's nothing you would do to make the memory manager directly decide to swap out a page. Other perhaps than minimizing your program's main window, that triggers the memory manager to aggressively trim the working set (= number of pages resident in RAM). Get a good memory profiler to get ahead.