为什么没有使用页面文件？

我遇到了Windows Server 2008 R2 Enterprise的问题。分页池加载内存但不加载实际的页面文件（我在驱动器上有空间）。

实际上问题在于内存过载，我认为这就是问题所在。

虚拟memery设置：

页面文件的可用性： 内存使用量仍然慢慢增长

任务管理器性能：

任务管理器流程：

RAM地图：

系统信息：

第一条评论：“内核内存 - 分页”的显示，这里几乎是22 GB，是分页池的虚拟大小。

Windows中的“池”是内核空间堆存储。内核驱动程序和Windows内核模式代码使用它们的方式与用户模式程序使用的方式大致相同，但它们位于内核地址空间，对所有进程都是通用的，当然，只能从内核模式访问。有几种类型的池分配，但它们分解为“非分页”和“分页”区域。非分页池始终驻留在RAM中。

页面缓冲池实际上应该被称为“可分页”池，因为被称为“页面缓冲池”并不意味着它被分页出RAM，或者它必然会被分页。它确实意味着它与大多数用户模式分配一样被分页。

与用户模式分配一样，我们可以预期，在任何时候，页面缓冲池的虚拟大小的某些子集将在RAM中“驻留”或“有效”（可在不发生页面错误的情况下访问;此类RAM被视为“正在使用中” ）; 另一个子集将“处于转换状态”（在备用或修改的页面列表上，可访问但具有软页面错误），其余的将被真正分页 - 在页面文件中，需要访问硬页面错误。

现在，22 GB是很多页面缓冲池。我的意思是，真的非常非常。这样的数量是非常不寻常的。我怀疑你有一个故障的设备驱动程序，像筛子一样泄漏分页内存。

我会使用poolmon或Windows Performance Toolkit来找出分配了所有池的内容。SU上有很多答案，详细说明了如何做到这一点。

在对您的问题的评论中，magicandre1981与他的一个答案相关联，详细说明了该程序。

除此之外，似乎有些东西阻止了对页面文件的写入。

来自RAMmap的屏幕上限（并且感谢您包括它）显示占用RAM的19 GB页面缓冲池（注意，这小于虚拟大小），大约620 MB它是“活动的”。意味着大量RAM被认为是“在使用中”。这是可以在没有页面错误的情况下访问的部分。描述这些虚拟页面的PTE设置了“有效”位。

几乎相同的数量，约680 MB，在待机页面列表中。

然后这是第二个问题的指标：超过17 GB位于“已修改”列表中。

“已修改”页面列表是指页面在从内容进行修改后从工作集中移出后放置的位置。（如果页面的内容未被修改，因为它被分页，那么当它被打开时从它的工作集丢失它只是放在待机页面列表，“可用”RAM的一部分，并立即可再利用其他用途。）这些页面不能简单地发布供其他进程使用; 他们的内容必须保存。对于页面文件支持的页面，“已保存”表示“写入页面文件”。

将已修改的页面写入磁盘后，它将被移动到备用列表，从该列表可以重新调整用途。备用列表计为“可用”RAM的一部分。（它也是该任务管理器显示中“缓存”计数器的一部分。）

因此，在修改后的页面列表中有超过17 GB的RAM - 您的系统希望将RAM写入页面文件的RAM。

这非常过分。

大多数系统在修改后的列表中的RAM不超过百分之几。每当修改后的列表超过一个小阈值时，系统进程中就会有一些线程负责将修改后的页面写回磁盘。他们没有做好这份工作。

我注意到您当前的页面文件大小约为5 GB，并且每个WMI输出它已满。（所以你的系统正在写入页面文件。）但是，由于某些原因，页面文件扩展似乎没有发生。

嗯 - 您已将页面文件大小限制为最大20 GB，即使它已扩展到该大小，也不足以保持其当前内容加上17 GB以上。也许如果你将最大可能的PF尺寸放大（Windows建议将近40 GB），那么事情就会失败。

但我对此表示怀疑。我认为Windows没有理由不将页面文件扩展到极限。没错，它不能容纳所有修改过的页面，但是保留大部分页面比将它们中的大部分保存在RAM中要好得多。

同时，那些17+ GB不可用于其他用途。这就是你的“可用”RAM如此之低的原因。

我们已经看到页面文件大小中的错误被清除：

• 将页面文件设置为禁用
• 关闭并重启
• 确保旧的页面文件消失了。如果没有，删除它。
• 将页面文件大小设置为合理的
• 如有必要，请关闭并重新启动

你可以尝试一下。

但你真正的问题是你真的不应该首先需要20 GB的分页池。找到并解决这个问题。

之后，您应该再次检查页面文件的使用情况，并将其初始大小设置为常规使用量的至少两倍。没有充分的理由将初始尺寸设置为小于您的系统通常需要的尺寸。（我喜欢看到页面文件的使用率不超过25％，原因与空间分配算法有关 - 它们可以在有大量可用空间的情况下更好地工作。）

顺便说一句，“待机”和“修改”页面（在我看来有点误导）被视为任务管理器屏幕上“缓存”的一部分。因此，你有17.4 GB“修改”的事实解释了巨大的“缓存”数字。巨大的“缓存”数字本身并不是问题; 这是其中一个症状。

分页池是内核模式代码的分类。内核模式代码将使用分页或非分页池进行操作，某些操作要求使用某种类型。这可能会也可能不会被页面文件支持。由操作系统来分配和使用分页。事实上，分页会花费你的I / O，因此操作系统更愿意在物理上尽可能多地保留。对于x64位操作系统，24 GB物理是我看到的配置。操作系统可以很好地管理主存储器中的大多数操作。

https://technet.microsoft.com/en-us/library/ff382715.aspx

以上参考将有助于了解缓存大小。

我不认为这是一个问题。除了您使用过的工具中显而易见的指标外，我也无法详细说明。

编辑： - 在所有分析“看到~40条评论”之后，罪魁祸首被发现是第三方驱动程序。在一流的分析/指示的帮助下进行分析，这确实是一个问题（信用：Jamie Hanrahan）和分页池分析（信用：Magicandre）。需要进一步分析来回答实际问题。