有啥方法可以强制 C++ 中进程的 WorkingSet 为 1GB？

Posted 2023-02-21

【中文标题】有啥方法可以强制 C++ 中进程的 WorkingSet 为 1GB？

【英文标题】：Is there any way to force the WorkingSet of a process to be 1GB in C++?有什么方法可以强制 C++ 中进程的 WorkingSet 为 1GB？

【发布时间】：2012-09-01 13:50:36

【问题描述】：

如果我在 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++ 项目。

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

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

更新

最后，我们最终忽略了这个问题，因为它并没有对性能产生太大影响。

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

换句话说，如果要减少软页错误，SetProcessWorkingSetSizeEx 绝对没有效果，因为它指的是硬页错误。

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

【问题讨论】：

您如何期望操作系统在内存中保留比您分配的更多的页面？

那你为什么要释放内存呢？

如果您的垃圾收集器对您的性能影响如此之大，那么是时候查看您的分配策略了。

可以（有时）重复使用对象（池化对象）。仅仅因为有 GC 并不意味着您无法控制何时分配和释放对象。

@Gravitas：你错失了重点。工作集分配了当前位于 RAM 中的内存块，而不是您可以直接控制的内存块。是的，您可以分配一个块以使您的工作集大小达到某个值，但是一旦发布，它就消失了，不再可用，或者是工作集的一部分。它不会神奇地将操作系统页面重新放入其他页面或保留它以供您的进程使用。要停止内存被换出，不要释放它们或继续使用它们。

【参考方案1】：

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

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

为了具体回答您的问题 - 当您刚刚使用 GC.Collect() 时发生的页面错误不是页面错误，它们是由 GC 导致的需求归零页面错误刚刚分配了一个新的巨大的需求归零页面块来移动你的对象。您的页面文件不会为需求零页面提供服务并且不会产生磁盘成本，但它们仍然是页面错误，因此它们会显示在您的图表上。

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

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

【讨论】：

我们使用 Microsoft Concurrency Visualizer 来深入了解应用程序中发生的情况。最后，性能损失还不足以担心。