6

如果我在 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 时软页面错误（红色尖峰）的数量急剧增加。

显示当 WorkingSet 减少得太低时软页面错误增加的示例

更新

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

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

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

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

4

1 回答 1

4

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

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

要专门回答您的问题 - 当您刚刚有 GC.Collect() 时发生的页面错误不是页面错误，它们是由 GC 刚刚分配的事实引起的需求归零页面错误一大块新的需求归零页面，可将您的对象移动到其中。您的页面文件不会为需求零页面提供服务并且不会产生磁盘成本，但它们仍然是页面错误，因此它们会显示在您的图表上。

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

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

于 2012-09-06T11:56:46.470 回答