Question

我的MMF课程中有这个功能

    void Clear() {
        int size = SizeB();
        int iter = size / sysInfo.granB;
        for (int i = 0; i < iter; i++) {
            auto v = (char*)MapViewOfFile(hMmf, FILE_MAP_READ | (write ? FILE_MAP_WRITE : 0), 0, i * sysInfo.granB, sysInfo.granB);
            std::memset(v, 0, sysInfo.granB);   
            UnmapViewOfFile(v);
        }
    }

所以它做的是以最小的可寻址块（在这种情况下为64k）遍历整个文件，映射视图，写入0，取消映射，重复。它工作正常并且非常快，但是当我使用它时，会有一些幻像内存使用。

根据Windows任务管理器的说法，进程本身只使用几兆字节，但当我在较大的文件上使用它时，“物理内存使用率”会上升。例如，在2GB文件上使用它足以让我的笔记本电脑处于昏迷状态几分钟，物理内存使用率达到99％，任务管理器中的所有内容都疯狂地减少了内存，一切都冻结了一段时间。

我试图在64k块中执行此操作的全部原因是为了保持内存使用率下降，但在这种情况下块大小并不重要，任何大小的块* n覆盖文件都会做同样的事情。

我尝试了很多事情：

在取消映射之前刷新视图 - 这会让事情变得非常缓慢，在任何大小的块中执行2gb文件需要10分钟。
在循环中添加硬编码延迟 - 它实际上工作得很好，它仍然可以在几秒钟内完成，内存使用率保持不变但我真的不喜欢任何循环中硬编码延迟的概念
将0写入文件的末尾 - 我实际上不需要清除文件，只是强制它准备好使用。我的意思是 - 当我创建一个新文件并从我的随机IO开始时，我最多只能达到1MB / s。如果我先打开现有文件或强制在新文件中写入0，我的速度会更好。我不确定为什么会这样，但是另一个线程中的用户建议在设置文件指针之后在文件的最末端写一些东西与清除具有相同的效果，但是从测试开始，这不是真的。

所以目前我正试图从清除文件的角度解决这个问题而不破坏计算机内存。有人知道如何适当地限制这个循环吗？

Answer 1

所以这就是事情。当您MapViewOfFile时，它会分配相关的内存范围，但可能可能会将其标记为已换出（例如，如果它尚未被读入内存）。如果是这种情况，那么当您第一次访问它时会出现页面错误（这将导致操作系统读取它）。

然后，当您UnmapViewOfFile时，操作系统获取相关内存范围的所有权，并将现在不可访问的用户空间数据写回磁盘（当然，假设您已写入磁盘），这将页面标记为“脏”，否则直接取消分配）。引用the documentation（我请你在评论中阅读）：modified pages are written "lazily" to disk; that is, modifications may be cached in memory and written to disk at a later time.

取消映射文件的视图不能保证“取消提交”并将数据写入磁盘。而且，即使CloseHandle也没有提供这种保证。它只是关闭它的手柄。由于缓存机制，如果您不调用FlushViewOfFile，则完全允许操作系统在其自己的时间将数据写回磁盘。即使重新打开相同的文件可能只是从缓存而不是从磁盘中提取数据。

最终问题是

你的内存映射文件
你写到记忆地图
写入内存映射的地址范围会导致从磁盘读入文件的映射
取消映射文件
取消映射文件“lazily”将数据写回磁盘
操作系统可能会达到内存压力，看到有一些未写入的数据现在可以写入磁盘，并强制发生这种情况以恢复物理内存以进行新的分配;顺便说一句，由于操作系统懒洋洋地刷新，你的IO不再是顺序的，导致主轴磁盘延迟大幅增加

当你正在睡觉时，你会看到更好的表现，因为你给操作系统提供机会说“嘿，我没有做任何事情......让我们继续并刷新缓存”，这会强制磁盘IO大致顺序。

为什么这个循环会破坏我的记忆？

1 个答案: