从我上次问题，另一个问题浮现在我的脑海中。正如那里提到的，内存不足会导致操作系统在 Windows 中使用页面文件，内存不足还会导致 superfetch 等服务运行得更多。所以我的问题是：
由于资源不足的情况下需要进行内存管理，内存不足是否会导致 CPU 使用率升高（甚至略高）？如果答案是肯定的，那么这合理吗？
答案1
内存不足会导致操作系统将内存从最近最少使用的应用程序移出到页面文件。这需要一些 CPU 开销来管理将数据写入磁盘的操作。
稍后，当应用程序读取或写入已分页到磁盘的内存时，将引发“页面错误”异常。然后任务被暂停，操作系统找出内存在磁盘上的存储位置，将其读入物理 RAM，修改应用程序的页表以指向新的物理内存位置，然后取消暂停任务。
所有的劳动成本一些如果有足够的物理内存，则不需要占用 CPU 时间。与其他操作相比，这个时间可能相对较小，但仍然是一个可观的数量。
所以是的，内存不足会导致 CPU 使用率升高。
问题是内存非常低会导致内存匮乏，以至于系统分页进出太多数据，以至于磁盘输入和输出时间主导了所有其他事情。
答案2
快速回答：是的......嗯，有点......但在极端情况下它会产生相反的效果，至少在 CPU 使用率百分比方面。
如今，在典型的“RAM 不足”情况下，您不会看到硬页面错误率大幅增加，但您会看到总体页面错误率更高（额外的错误是软错误）。软错误不涉及磁盘 IO。但代码必须在内存管理器中运行才能解决该错误。
我估计解决软故障的时间大约需要几百条指令。因此，如果每一个如果您的工作负载尝试执行的指令引发了软故障，那么您的工作将需要大约 300 倍的时间才能完成！假设这项工作全部受 CPU 限制。（幸运的是，引发软故障的指令百分比远没有那么高。）
但这不会增加测量的CPU使用率百分比！线程要么正在运行，要么没有运行，从 CPU 使用率计数器来看，运行应用代码所花的时间与内存管理器代表应用解决软故障所花的时间之间没有……嗯，几乎*没有……明显的区别。Mm 在故障进程的上下文中运行，因此其 CPU 时间只是进程时间的一部分。
*差异将显示在内核模式和用户模式下所花费的时间上，因为 Mm 当然在内核模式下运行。
当然，如果您的应用程序必须在内存管理器上花费大量时间，那么实际完成的工作就会少很多！但测量的 CPU 使用率 % 不会改变。
什么将要变化是您的线程或进程完成相同实际工作所需的 CPU 时间总量（秒，而不是%）。
更极端的情况是，您经常向磁盘进行分页，即发生硬页面错误。
这实际上减少测量的 CPU 使用率百分比，因为等待分页 I/O（或任何其他 I/O）完成所花费的时间不是在 CPU 中运行代码所花费的时间。在 I/O 期间，请求线程处于等待状态，或者如 *nix 所称的“阻塞”。存储设备（磁盘甚至 SSD）执行 I/O 所花费的时间完全淹没了在内存管理器中设置 I/O 所花费的 CPU 时间；因此后者变得可以忽略不计。这在较小程度上适用于 M.2 SSD。
因此，在硬故障率较高的情况下，你会看到 CPU 使用率以百分比表示，减少. （即驱动器成为 CPU 的瓶颈。）就像您的应用程序花费大量时间读取数据文件一样。
但当然，你会发现你的应用需要更长的时间才能完成你想要它做的工作。就像软故障的情况一样，只会更糟糕。
注意：页面文件并不是唯一用于分页的文件！系统中的每个映射文件（包括每个进程使用的每个 exe 和 dll，以及 ntoskrnel 本身）本质上都是页面文件。因此，删除页面文件不会消除硬故障或磁盘分页。
答案3
我认为将磁盘交换为使用内存会使 CPU 具有更长的 I/O 周期，从而导致更普遍的停滞，因为 CPU/RAM 本质上是以较慢的速度接收数据的。特别是如果你有一个像 Ryzen CPU 这样的 CPU，它们总是渴望更多的 RAM 带宽，是的，它确实会开始对 CPU 产生不利影响。我想这确实取决于究竟是什么获得了页面文件，但从根本上讲，它会让 CPU 在某些调用上等待更长时间，从而使其工作速度变慢。希望这能回答你的问题 :)
编辑：页面归档的位置也很重要，我想 M.2 SSD（或任何 SSD）对 CPU 的帮助比 SATA HDD 更大。
编辑2：请阅读此帖子下方的 Jamie 的评论。