c# - 将事件内存分页到磁盘的速率极高，但持续内存使用率较低

Question

如标题所述，我遇到了高页面文件事件的问题。

我正在开发一个处理大量图像的程序，这些图像从硬盘驱动器加载。它从每张图片生成一些数据，我将这些数据保存在列表中。对于每 3600 张图像，我将列表保存到硬盘，其大小约为 5 到 10 MB。它以尽可能快的速度运行，因此它最大化了一个 CPU 线程。

程序运行正常，它生成了它应该生成的数据，但是当我在 Visual Studio 中分析它时，我收到一条警告:DA0014: Extremely high rates of paging active memory to disk .

根据任务管理器，该程序的内存消耗约为 50 MB，而且似乎很稳定。当我运行该程序时，我在 4 GB 中还剩下大约 2 GB，所以我想我没有用完 RAM。 http://i.stack.imgur.com/TDAB0.png

DA0014 规则描述说“例如，页面输出/秒的数量通常远大于页面写入/秒的数量。因为页面输出/秒还包括来自系统文件缓存的已更改数据页面。但是，确定哪个进程直接负责分页或为什么直接负责并不总是那么容易。”

这是否意味着我收到此警告只是因为我从硬盘读取了很多图像，还是另有原因？不太确定我在寻找哪种错误。

编辑:插入图片的链接。

EDIT1:每个图像大小约为 300 KB。在加载下一个之前，我会处理掉每个。

更新:从实验来看，分页只是加载了大量文件。由于我不是 C# 或底层 GDI+ API 方面的专家，所以我不知道哪个答案是最正确的。我选择了 Andras Zoltans 的回答，因为它得到了很好的解释，而且他似乎做了很多工作来向像我这样的新人解释原因:)

Answer 1

更新了更多信息

您的应用程序的工作集可能不是很大 - 但虚拟内存大小如何？分页可能因此而发生，而不仅仅是因为它的物理尺寸。请参阅来自 Process Explorer 的屏幕截图在 Windows 8 上运行的 VS2012:

在任务管理器上呢？显然，同一进程的私有(private)工作集为 305,376Kb。

我们可以从中得出 a) 任务管理器不一定可信，b) 就操作系统而言，应用程序在内存中的大小远比我们想象的要复杂。

你可能想看看这个。

分页几乎可以肯定是因为您对文件所做的操作，而最终数字高几乎可以肯定是因为您正在处理的文件数量。一个简单的测试是用不同数量的文件进行实验，并生成一个包含最终分页数字的数据集。如果文件数量导致分页，那么您会看到明显的相关性。

然后取出您所做的任何处理(但保持图像加载)并再次比较 - 注意差异。

然后完全删除图像加载代码——注意区别。

很明显，当您去除图像加载时，您会看到最大的故障下降。

现在，查看 Emgu.CV Image code ，它在内部使用 Image 类来获取图像位 - 因此通过函数 GdipLoadImageFromFile (Second entry on this index) 启动 GDI+ ) 解码图像(使用系统资源，加上潜在的大字节数组)- 然后将数据复制到包含实际 RGB 值的未压缩字节数组。

此字节数组使用 GCHandle.Alloc(也被 GC.AddMemoryPressure 和 GC.RemoveMemoryPressure 包围)分配以创建固定字节数组来保存图像数据(未压缩)。现在我不是 .Net 内存管理方面的专家，但在我看来，即使每个文件按顺序加载而不是并行加载，我们这里也有可能出现堆碎片。

我不知道这是否会导致硬分页。但这似乎很有可能。

特别是图像的内存表示可以专门用于显示，而不是原始文件字节。因此，例如，如果我们谈论的是 JPEG，那么 300Kb JPEG 的物理内存可能会大得多，具体取决于其大小。例如。一个 1027x768 的 32 位图像是 3Mb - 从加载(第一次分配)然后复制(第二次分配)到 EMGU 图像对象之前，它被分配了 两次 到 EMGU 图像对象。

但是你必须问问自己是否有必要找到解决问题的方法。如果您的应用程序不消耗大量物理 RAM，那么它对其他应用程序的影响就会小得多；如果有足够的物理内存，一个进程会大量访问页面文件不会对另一个不会产生严重影响的进程产生严重影响。