c++ - 在 C++ 中，有什么方法可以强制进程的 WorkingSet 为 1GB？

Question

如果我在 C++ 中使用以下调用，我希望进程的 WorkingSet 永远不会低于 100MB。

但是，即使我进行此调用，操作系统仍将工作集缩减为 16MB。

将 WorkingSet 设置为 100MB 会通过消除软页面页面错误(参见下图)显着提高我的应用程序速度。

我做错了什么？

SIZE_T workingSetSizeMB = 100;
int errorCode = SetProcessWorkingSetSizeEx(
    GetCurrentProcess(),
    (workingSetSizeMB - 1) * 1024 * 1024), // dwMinimumWorkingSetSize
    workingSetSizeMB * 1024 * 1024,  // dwMaximumWorkingSetSize,
    QUOTA_LIMITS_HARDWS_MIN_ENABLE | QUOTA_LIMITS_HARDWS_MAX_DISABLE
  );
// errorCode returns 1, so the call worked.

(专家额外) 实验方法论

我编写了一个测试 C++ 项目来分配 100MB 的数据以使 WorkingSet 超过 100MB(在 Process Explorer 中查看)，然后释放该内存。但是，一旦我释放该内存，操作系统就将 WorkingSet 缩减为 16MB。如果您愿意，我可以提供我使用的测试 C++ 项目。

为什么 Windows 提供对 SetProcessWorkingSetSizeEx() 的调用，如果它似乎不起作用？我一定是做错了什么。

下图显示了当绿线(工作集)从 50MB 下降到 30MB 时，软页面错误(红色尖峰)的数量急剧增加。

更新

最后，我们忽略了这个问题，因为它对性能影响不大。

更重要的是，SetProcessWorkingSetSizeEx 不控制当前的 WorkingSet，并且 不以任何方式与软页面错误相关。它所做的只是通过防止当前 WorkingSet 被分页到硬盘驱动器来防止硬页面错误。

换句话说，如果要减少软页错误，SetProcessWorkingSetSizeEx 完全没有作用，因为它指的是硬页错误。

“Windows via C/C++”(Richter)中有一篇很棒的文章介绍了 Windows 如何处理内存。

Answer 1

页面错误很便宜并且是可以预料的。实时应用程序、高端游戏、高强度处理和蓝光播放都可以在页面错误的情况下全速运行。页面错误不是您的应用程序运行缓慢的原因。

要找出您的应用程序运行缓慢的原因，您需要对您的应用程序进行一些应用程序分析。

具体回答你的问题 - 当你刚刚有一个 GC.Collect() 时发生的页面错误不是页面错误，它们是由 GC 引起的需求归零页面错误刚刚分配了一个新的巨大的需求归零页面 block 来将您的对象移动到。请求零页不从您的页面文件中得到服务并且不会产生磁盘成本，但它们仍然是页面错误，因此它们显示在您的图表上。

作为一般规则，Windows 比您更擅长管理系统资源，并且它的默认设置针对普通程序的一般情况进行了高度调整。从您的示例中可以清楚地看出您正在使用垃圾收集器，因此您已经将处理工作集和虚拟内存等的任务卸载到 GC 实现中。如果 SetProcessWorkingSetSize 是提高 GC 性能的良好 API 调用，那么 GC 实现会做到这一点。

我对您的建议是分析您的应用。托管应用程序运行缓慢的主要原因是编写糟糕的托管代码——而不是 GC 拖慢了您的速度。提高算法的 big-O 性能，通过使用 Future 和 BackgroundWorker 之类的东西来卸载昂贵的工作，并尽量避免对网络进行同步请求——但最重要的是，让你的应用程序快速运行的关键是 profile 它。