远离Windows \ C ++中的虚拟内存

Question

我正在编写一个性能关键型应用程序，它必须在转储到光盘之前将尽可能多的数据存储在物理内存中。

我可以使用::GlobalMemoryStatusEx(...)和::GetProcessMemoryInfo(...)来查找保留的物理内存百分比\以及当前进程处理的内存量。 使用这些数据，我可以确保在使用~90％的物理内存时进行转储，或者每个应用程序限制最多2GB的约90.

但是，我想要一种方法来简单地接收系统开始使用虚拟内存之前实际剩余的字节数，特别是当应用程序将被编译为32位和64位时，而2 GB限制不存在。

Answer 1

这个功能怎么样：

int
bytesLeftUntilVMUsed() {
    return 0;
}

它应该在我认为的几乎所有情况下给出正确的结果;）

Answer 2

想象一下，在256Mb的RAM中运行Windows 7（MS建议至少1GB）。这实际上就是你要求用户想要重新获得90％的可用RAM。

真正的问题是：你为什么需要这么多内存？什么是“绩效关键”标准？

通常，这类问题意味着您的设计存在严重错误。

更新

使用范围顶部RAM（DDR3）可以提供12GB / s的理论传输速度，相当于每个时钟周期读取一个32位值，并留有一些带宽。我很确定不可能对以这种速度进入CPU的数据做任何有用的事情 - 指令处理停顿会中断这个流程。额外的，未充分的带宽可用于向/从硬盘寻呼数据。使用RAID，这种传输速率可能非常高（约为RAM带宽的1/16）。因此，将数据传输到磁盘或从磁盘传输数据而不会降低性能是可行的 - 读取之间只需要16个循环（好吧，我的数学可能有点不对劲）。

但是如果你把Windows扔进混音中，那一切都会变成底池。你的记忆随时都可以消失，你的应用程序可以随意暂停，等等。将内存锁定到RAM会对整个系统产生不利影响，从而破坏了查找内存的目的。

如果你解释一下你想要实现的目标和性能评论，那么这里有很多人会帮助开发一个合适的解决方案，因为如果你不得不询问系统限制，那么你确实做错了什么。

Answer 3

即使您能够阻止您的应用程序将内存分页到磁盘，您仍然会遇到VMM可能将其他程序分页到磁盘的问题，这可能会也可能影响您的表现。更不用说另一个应用程序可能会启动并占用您当前占用的内存，从而导致某些应用程序内存被分页。你打算怎么处理这个问题？

有一种方法可以通过non-paged pool使用不可分页的内存，但是（a）这个池相对较小，（b）它被设备驱动程序使用，并且可能只能从内核中使用。除非你想确保你的系统不稳定，否则也不建议使用它的大块。

您可能想要重新访问应用程序的设计，并尝试在尝试编写自己的VMM或将Windows计算机转换为具有更多内存的DOS框之前，将内存分页到磁盘的可能性。 / p>

Answer 4

标准解决方案是不要担心“虚拟”而担心“动态”。

虚拟内存的“虚拟”部分必须被视为一种硬件功能，您只能通过编写自己的操作系统来解决这个问题。

然而，对象的动态分配只是应用程序的设计。

静态分配您需要的对象的简单数组。使用那些对象数组。增加和减少这些静态分配的数组的大小，直到遇到性能问题。

Answer 5

哎哟。非页面缓冲池（无法交换或分配给进程的RAM量）通常为256 MB。这是2GB机器上12.5％的RAM。如果将另外90％的物理RAM分配给进程，则对于所有其他应用程序，服务，内核和驱动程序，这将留下-2.5％。即使你只为你的应用程序分配了85％，这仍然只会留下2.5％= 51 MB。