问题标签 [pagefile]

storport 驱动程序能否知道是否收到了读/写命令请求，是因为来自物理 RAM 的 Paging out 请求还是对 RAM 的 Paging in 请求？

这个问题与任何特定的代码甚至语言都没有真正的关系。

如果您在 Windows 上分配大量（超过物理内存）内存，则会导致整个操作系统完全无响应 - 包括通常即使整个系统崩溃也能够移动的鼠标光标。

工作集 API 似乎无法解决问题 - 似乎所有应用程序的初始最大工作集大小都已设置为相当低的水平。

我希望内存映射文件（通过 boost api）可以帮助操作系统对页面加载/卸载做出更好的决定——但同样，即使是大数据的单通道也会冻结系统。

是否有任何神奇的 WinAPI 调用或其他良好的编程实践（除了手动管理整个提交的内存和文件中的手动数据缓存）可以在使用如此大量的数据时保持操作系统和其他应用程序相当稳定？

我有一个在 Windows 上运行的软实时应用程序，它以 10Hz 的频率循环运行。通常，它能够在 2-3ms 内完成一个周期，然后休眠直到下一个 100ms 窗口开始。

我观察到时不时地，一个周期会超过 400 毫秒。我一直在使用 Windows Performance Recorder 进行调查，发现当这些事件发生时，附近的线程立即停止在 CPU 上运行，磁盘利用率增加到 100%，并且文件 I/O 显示正在读取可执行文件本身磁盘（硬盘）。随后是硬页面错误，然后 CPU 恢复线程。

这种相同的行为经常被观察到，但通常分页操作花费的时间相对较短，可能是 50-60 毫秒。这将向我表明 Windows 正在将应用程序的部分交换进出 RAM，并且页面文件可能已满。导致页面错误的应用程序部分各不相同，但每次循环都会触及代码（通过内部分析验证），因此它必须在循环之间的空间中卸载。

该机器的规格是硬盘驱动器和 8GB 内存，页面文件大小为 1,024MB（由 Windows 设置），在 Windows 10 上运行。不幸的是，更改操作系统是不可能的。

为了解决这个问题，我可以看什么：

1. 将 HDD 换成 SSD。
2. 增加交换文件的大小，以便可以一次分配整个程序。
3. 完全删除交换文件以试图强制整个应用程序始终驻留在 RAM 中。

我的解决方案的潜在问题：

1. 能够获得更改硬件的许可将很困难，因为我不能确定它会解决问题，而且在不确定的情况下，能够说服管理层的可能性很低。
2. 我的理解是，即使增加页面文件的大小也可能无法完全解决问题，因为更多的程序将能够使用它。这将是反复试验，直到我找到一个可以容纳机器上运行的所有东西的大小，并且由于该问题相对不常见，因此很难验证。
3. 从理论上讲，立即将所有内容加载到 RAM 中听起来像是一个解决方案（不包括需要触摸每个功能才能这样做的事实），但我不知道这可能会产生任何潜在的副作用。机器上的 RAM 使用率仍然很低，我的应用程序没有动态内存分配，但这忽略了所有其他可能在后台运行的应用程序。