我有2GB RAM和运行内存密集型应用程序和要低可用物理存储器状态和系统不响应用户动作，如打开的任何应用程序或菜单调用等内存映射文件会导致较低的物理存储器
如何触发或告诉系统将内存交换为页面文件和空闲物理内存？ 我正在使用Windows XP。
如果我在4GB RAM机器上运行相同的应用程序，情况并非如此，系统响应良好。在获得可用的物理内存系统之后，系统会自动交换页面文件和空闲物理内存，这不像2GB系统那么糟糕。
为了克服这个问题（在2GB机器上），试图将内存映射文件用于由应用程序分配的大型数据集。在这种情况下，应用程序（进程）的虚拟内存很好，但系统缓存很高，与上述物理内存较少的问题相同。
即使内存映射文件未映射到进程虚拟内存系统缓存很高。为什么？？？！！！ :(
任何帮助表示赞赏。 感谢。
当我想你在您的文章被暗示，缓慢的响应时间可能至少部分是由于系统延迟，而OS写的内容内存到页面文件，以便为物理内存中的其他进程腾出空间。
显而易见的解决方案（也可能不实用）是在应用程序中使用更少的内存。我假设这不是一个选项，或者至少不是简单的选择，另一种方法是尝试主动将数据刷新到磁盘上，以便为其他应用程序持续运行提供物理内存，您可以在mach上查找总内存与GlobalMemoryStatusEx。而GetProcessMemoryInfo将返回关于您自己的应用程序的内存使用情况的当前信息。既然你说你正在使用内存映射文件，你可能还需要考虑这一点。例如，我相信从该API返回的PageFileUsage信息将不包含有关您自己的内存映射文件的信息。
如果您的应用程序正在监视使用情况，您可能可以使用FlushViewOfFile主动从内存强制数据到磁盘。还有一个API（EmptyWorkingSet），我认为它试图尽可能多地将脏页写入磁盘，但是这看起来很可能会极大地损害您自己的应用程序的性能。虽然，在知道应用程序进入某种空闲状态的情况下，它可能会很有用。
最后，另一个可能有用的API是SetProcessWorkingSetSizeEx。您可能会考虑使用此API为您的应用程序的工作集大小提供上限提示。这可能有助于为其他应用程序保留更多内存。
编辑：这是另一个明显的说法，但我忘了提前它。这对您来说也可能并不实际，但听起来您考虑到您遇到32位限制时可能做的最好的事情之一是将您的应用程序构建为64位并在64位操作系统上运行它（并在机器上放一点点内存）。
如果您使用内存映射文件的数据访问模式是连续的，则通过在打开基础文件时指定FILE_FLAG_SEQUENTIAL_SCAN标志可以获得稍好的页面回收。如果您的数据模式以随机顺序访问映射文件，这将无济于事。
您应该考虑减小地图视图的大小。这就是所有内存都被实际消耗和缓存的地方。由于看起来您需要处理大于可用连续空闲物理内存的文件，因此您可能比虚拟内存页面交换器更好地进行内存管理，因为您比使用虚拟内存知道更多关于内存使用情况的内容内存管理器呢。如果可能的话，尝试调整您的设计，以便您可以使用较小的视图对大文件的某些部分进行操作。
即使您无法摆脱底层文件整个范围内的完全随机访问需求，仍然可以根据需要拆除并重新创建视图以将视图移动到下一个操作需要访问的文件。如果您的数据访问模式趋向于在继续前进之前围绕文件的某些部分聚集，则无需经常移动视图。您会点击拆除并重新创建视图对象，但由于拆除视图也会释放与该视图关联的所有缓存页面，因此您可能会看到性能上的净增益，因为较小的视图显着减少内存压力和页面交换系统。尝试根据安装的系统RAM的一部分设置视图的大小，并根据文件处理的需要移动视图。视图越大，需要将其移动的次数越少，但消耗的RAM越多，这可能会影响系统响应能力。
嗯，这听起来像你的程序需要超过2GB的工作集。
现代操作系统被设计为在任何时候都将大部分内存用于某些内容，只保留相当少量的空闲空间，以便可以立即将其分发给需要更多内存的进程。其余部分用于保存最近使用过的内存页面和高速缓存的磁盘块;最近未使用的任何内容都会刷新到磁盘以补充免费页面池。总之，没有假设是多余的物理内存。
使用正常的内存分配和映射文件的内存之间的主要区别在于当数据必须被分页出内存时数据被存储的地方。它不一定对内存何时被分页有任何影响，并且对分页时间几乎没有影响。
您看到的真正问题可能不是您的物理内存太少，而是分页速率太高。
我的建议是尝试减少程序所需的存储量，并查看是否可以增加引用的局部性以减少所需的分页量。