我想优化页面文件大小以满足我的实际需求。我想遵循 Mark Russinovich 建议的公式：最小值应为峰值提交减去物理 RAM，最大值应为其两倍。
为了确保我做的一切都正确，我想澄清以下几点：
1) 这个红色的数字是Russinovich先生提到的Peak Commit吗？
屏幕上是进程探索器
2）在“控制面板”>“系统”中，它显示我的安装的 RAM 为 4 GB，只有 2.45 GB 可用。显然，在任务管理器中我的总物理内存也是 2509 MB。那是因为我的操作系统是 32 位的。所以，我是否正确理解了这个 2509（而不是 4GB）是我应该用于页面文件大小计算的数字？
我知道问这个可能有点傻，但正如我已经说过的，我想确保我做对了。
非常感谢。
答案1
你肯定指的是“突破 Windows 的极限：虚拟内存”作者：马克·鲁西诺维奇（Mark Russinovich）。
- 是的，就是这个号码。
- 是的，您只能使用 2.5 GB 的 RAM（大约 - 这里不需要过于精确）。
然而……你写的是“做对了”。我必须指出，马克的文章是关于“突破极限”的，而这个公式给了你一个绝对最低限度页面文件大小。如果您希望系统性能良好，您就不想“突破极限”。
这篇文章中没有建议你应该将设置设为那么小。只有当你真的想要时你才可以摆脱它。（假设你实际上永远不需要任何更多的已提交内存。）
（而且你可能需要更多。请记住，你在这里看到的这个“峰值”只是 Process Explorer 运行期间的峰值。只有当你恰好在那段时间内运行最大应用程序工作负载时，它才有意义。这并不意味着启动你认为会同时运行的所有应用程序。你还需要让每个应用程序使用你将要求的最大私有内存（“已提交”内存）。这是很难设置和测试的。谁能保证你永远不会在典型工作负载中添加另一个应用程序？因此，你通过监控工具获得的信息并不能保证你绝对不需要更多。）
请注意，如果您碰巧再次达到该峰值，并且您将页面文件设置为以这种方式计算的最小值，则 RAM 中将没有空间用于映射文件（例如代码文件，如 exe 和 dll）使用的 RAM。 （这是因为“已提交”虚拟内存的计数不包括代码页或由映射文件支持的其他页面。）由于代码必须在 RAM 中才能执行，所以这是一个问题。
好的，既然您启用了页面文件扩展，那么这不是一个“令人头痛”的问题。但它肯定会影响性能。
因此，除非您出于某种学术原因试图证明不会导致应用程序崩溃的绝对最小页面文件大小（无论是否存在性能问题），否则我不会这样做。（我想不出这样做的实际理由。）
如果你真的想把事情简化一下实际的最小，即不限制代码可用的 RAM，只需将页面文件最小大小设置为观察到的最大提交量即可。这意味着即使应用程序和操作系统创建了那么多提交内存（并引用了所有内存），代码仍然有 RAM 可用。
也没有理由将最大大小限制为最小大小的 2 倍，除非您非常关心磁盘使用情况。
您会看到，拥有大于系统所需的页面文件并没有什么坏处（除了磁盘空间占用）。特别是，大于必要的页面文件不会“吸引”更多页面。并且，将其设置为刚好足够大也没有任何好处（再次强调，除了磁盘空间占用）。那么，何必呢？也就是说，除了此练习占用的磁盘空间之外，您没有“优化”任何东西。
鉴于超出提交限制可能会导致应用程序崩溃（并因此导致数据丢失），并且在极少数情况下甚至会导致系统崩溃，因此我不太愿意将页面文件弄得尽可能小。
另一方面，如果系统必须大量写入页面文件（在只有 2.5 GB RAM 可用的 Windows 7 系统上，我想会这样），那么拥有一个比系统实际使用的大得多的页面文件将加快速度。为什么？因为如果有大量可用空间，用于页面文件的空间分配算法会快得多。
因此，我希望看到 PerfMon 计数器的 Pagefile %usage 保持在 25% 以下。