我在使用 Windows Server 2008 R2 Enterprise 时遇到了问题。分页池加载内存，但不会加载实际的页面文件（我的驱动器上有空间）。
实际上问题在于内存负载过大，我认为这就是问题所在。
虚拟内存设置：
页面文件可用性：
并且内存使用量仍然缓慢增长
任务管理器性能：
任务管理器进程：
RAM 映射：
系统信息：
答案1
第一条评论：“内核内存 - 分页”的显示，这里差不多有 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 的百分之几。每次修改列表超过一个小阈值时，系统进程中的线程应该负责将修改的页面写回磁盘。但它们并没有完成这项工作。
我注意到您当前的页面文件大小约为 5 GB，并且根据 WMI 输出，它已满。（因此您的系统是写入页面文件。）但由于某种原因，页面文件扩展似乎没有发生。
嗯 - 您已将页面文件大小限制为最大 20 GB，即使将其扩展到该大小，也不足以容纳其当前内容加上 17 GB。也许如果您将最大可能的 PF 大小设置得更大（Windows 建议将近 40 GB），那么事情就会变得顺利。
但我对此表示怀疑。我认为 Windows 没有理由不将页面文件扩展到极限。确实，它无法容纳所有已修改的页面，但保留大部分页面比将这么多页面保留在 RAM 中要好得多。
同时，这 17+ GB 不能“用于”其他用途。这就是“可用” RAM 如此低的原因。
我们发现页面文件大小存在错误，可以通过以下方法清除：
- 将页面文件设置为禁用
- 关机并重启
- 确保旧页面文件已消失。如果没有，请将其删除。
- 将页面文件大小设置为合理的值
- 如果有必要，请关闭并重新启动
你可以尝试一下。
但您的真正问题是，您实际上根本不需要 20 GB 的分页池。找到并修复该问题。
之后，您应该再次检查页面文件的使用情况，并将其初始大小设置为至少是常规使用量的两倍。没有理由将初始大小设置为小于系统常规需要的大小。（我希望页面文件的使用率不超过 25%，原因与空间分配算法有关 - 如果有足够多的可用空间，它们会工作得更好。）
顺便说一句，在任务管理器屏幕上，“待机”和“已修改”页面（在我看来有点误导）都算作“缓存”的一部分。因此，您有 17.4 GB 的“已修改”页面这一事实解释了“缓存”数字如此之大。“缓存”数字如此之大本身并不是问题；它只是症状之一。
答案2
分页池是内核模式代码的一种分类。内核模式代码将使用分页或非分页池进行操作，并且某些操作要求特定类型。这可能会或可能不会由页面文件支持。由操作系统分配和使用分页。实际上，分页会消耗 I/O，因此操作系统更愿意在物理内存中保留尽可能多的空间。据我所知，x64 位操作系统的配置为 24 GB 物理内存。操作系统可以很好地管理主内存中的大多数操作。
https://technet.microsoft.com/en-us/library/ff382715.aspx
以上参考将有助于了解缓存大小。
我不认为这是个问题。我可能也无法详细说明你所用工具中显而易见的指标。
编辑：- 经过所有分析“查看 ~40 条评论”，发现罪魁祸首是第三方驱动程序。分析是在一流的分析/指示的帮助下完成的，表明这确实是一个问题（来源：Jamie Hanrahan）和分页池分析（来源：Magicandre）。需要进一步分析才能回答实际问题。