问题标签 [memory-mapped-files]

对这个主题有所了解后，任何人都可以说出 POSIX 共享内存 (shm_open) 和 POSIX 映射文件 (mmap) 之间的真正区别是什么？

两者似乎都使用 /dev/tmpfs 子系统，而不是旧的 IPC 机制。

那么使用 mmap 文件而不是共享内存有什么优势吗？

谢谢。

我想知道是否有人尝试过新的 .NET 4.0 内存映射文件功能？我知道它们与 OS 一样古老，但 .NET 中的本机处理是新的。

有没有人能够对此进行测试并谈论性能？我对二进制文件随机部分的访问时间、写入速度等非常感兴趣。与本机 WinAPI MMF 的性能比较也会很好。

谢谢！

Microsoft 在 .Net 4 中引入了一个新的 System.IO.MemoryMappedFiles 命名空间。有人知道它是否支持备用数据流吗？谢谢！

我正在尝试在已映射到另一个 32 位进程的内存的文件上的 64 位进程中使用 MapViewOfFile。它失败并给我一个“拒绝访问”错误。这是已知的 Windows 限制还是我做错了什么？相同的代码适用于 2 个 32 位进程。

代码看起来像这样：

我有两个在 Windows XP 下运行的应用程序（进程），它们通过内存映射文件共享数据。尽管我尽一切努力消除每次迭代的内存分配，但每次数据传输我仍然会遇到大约 10 个软页面错误。我已经尝试了 CreateFileMapping() 和 CreateFileView() 中的每个标志，它仍然会发生。我开始怀疑这是否只是内存映射文件的工作方式。

如果有人知道内存映射文件背后的 O/S 实现细节，我将不胜感激对以下理论的评论：如果两个进程共享一个内存映射文件并且一个进程写入它而另一个进程读取它，那么 O/S 标记页面写入无效。当另一个进程去读取现在属于无效页面的内存区域时，这会导致软页面错误（通过设计），并且 O/S 知道重新加载无效页面。此外，软页面错误的数量因此与数据写入的大小成正比。

我的实验似乎证实了上述理论。当我共享数据时，我会写入一个连续的数据块。换句话说，每次都会覆盖整个共享内存区域。如果我使块更大，软页面错误的数量会相应增加。因此，如果我的理论是正确的，那么除了不使用内存映射文件之外，我无法消除软页面错误，因为它们就是这样工作的（使用软页面错误来保持页面一致性）。具有讽刺意味的是，我选择使用内存映射文件而不是 TCP 套接字连接，因为我认为它会更有效。

注意，如果软页面错误是无害的，请注意。我听说在某些时候如果数量过多，系统的性能可能会受到损害。如果软页面错误本质上并没有太大的危害，那么如果有人对每秒多少个“过多”有任何指导方针，我想听听。

谢谢。

或者再次从映射内存中重新读取该数据会更快，因为操作系统可能会实现自己的缓存？

事先不知道数据的性质，假设文件读取是随机的。

设想

我有以下方法：

最初我正在考虑在表单上存储：

和

AddItemSecurity是基于我如何从第三方 API 获取数据，GetValidItemIds是我想在运行时如何使用它。

可能有 2000 个用户和 1000 万个项目。项目 ID 的格式为：2007123456、2010001234（10 位数字，其中前四位代表年份）。

AddItemSecurity不必执行超快，但GetValidIds需要亚秒级。此外，如果现有的有更新，itemId我需要为不再在列表中的用户删除该 itemId。

我正在尝试考虑如何以最佳方式存储它。最好在磁盘上（带有缓存），但我希望代码可维护且干净。

如果项目 id 从 0 开始，我考虑MaxItemId / 8为每个用户创建一个长度为 的字节数组，并在项目是否存在时设置一个真/假位。这会将每个用户的数组长度限制为略高于 1mb，并提供快速查找以及更新每个用户列表的简单方法。通过使用 .Net 4 框架将其作为内存映射文件持久保存，我认为我也可以获得不错的缓存（如果机器有足够的 RAM），而无需自己实现缓存逻辑。每年解析 id、剥离年份并存储一个数组可能是一种解决方案。

ItemId -> UserId[] 列表可以直接序列化到磁盘并以正常方式读取/写入，FileStream以便持久化列表并在发生更改时对其进行比较。

每次添加新用户时，所有列表也必须更新，但这可以每晚完成。

问题

我应该继续尝试这种方法，还是应该探索其他路径？我认为 SQL 服务器的执行速度不够快，并且会产生开销（至少如果它托管在不同的服务器上），但我的假设可能是错误的。感谢您对此事的任何想法或见解。我想尝试在不添加太多硬件的情况下解决它:)

[2010-03-31更新]

我现在已经在以下条件下使用 SQL Server 2008 进行了测试。

• 具有两列 (userid,itemid) 的表都是 Int
• 两列的聚集索引
• 为 180 个用户添加了约 800.000 个项目 - 总共 1.44 亿行
• 为 SQL 服务器分配 4gb 内存
• 双核 2.66GHz 笔记本电脑
• SSD盘
• 使用 SqlDataReader 将所有 itemid 读入列表
• 遍历所有用户

如果我运行一个线程，它平均为 0.2 秒。当我添加第二个线程时，它会上升到 0.4 秒，这仍然可以。从那里开始，结果正在减少。添加第三个线程会使查询次数达到 2 秒。第四个线程最多 4 秒，第五个线程使某些查询达到 50 秒。

在这种情况下，CPU 正在运行，即使在一个线程上也是如此。由于快速循环，我的测试应用程序需要一些时间，其余部分需要 sql。

这使我得出结论，它不会很好地扩展。至少在我测试过的硬件上没有。有没有办法优化数据库，比如为每个用户存储一个 int 数组，而不是每个项目一个记录。但这使得移除项目变得更加困难。

[更新 2010-03-31 #2]

我使用相同的数据进行了快速测试，将其作为内存映射文件中的位。它的表现要好得多。六个线程产生的访问时间在 0.02 秒到 0.06 秒之间。纯内存绑定。映射文件由一个进程映射，并由另外六个进程同时访问。由于 sql base 占用了 4gb，磁盘上的文件占用了 23mb。

我试图向学生说明 Java 中传统 IO 和内存映射文件之间的性能差异。我在互联网上的某个地方找到了一个例子，但对我来说并不是一切都清楚，我什至不认为所有步骤都是必要的。我在这里和那里阅读了很多关于它的内容，但我不相信它们都不能正确实现。

我试图理解的代码是：

究竟什么时候需要使用RandomAccessFile？在这里它是用来读写的memoryMappedCopy，只是复制一个文件真的有必要吗？还是它是内存映射的一部分？

在customBufferedCopy，为什么synchronized在这里使用？

我还发现了一个不同的例子——应该——测试两者之间的性能：

我或多或少看到发生了什么，我的输出如下所示：

是什么让 Stream Read/Write 如此长的令人难以置信？作为一个读/写测试，对我来说，一遍又一遍地读取相同的整数看起来有点毫无意义（如果我很好地理解 中发生了什么Stream Read/Write）从先前写入的文件中读取 int 不是更好吗？在同一个地方读写整数？有没有更好的方法来说明它？

一段时间以来，我一直对很多这些事情感到头疼，但我无法了解整个情况。

我需要尽快将字典存储到文件中。键和值都是对象，不保证被标记为可序列化。此外，我更喜欢一种比序列化数千个对象更快的方法。因此，我研究了 .NET 4 中的映射内存文件支持。但是，MemoryMappedViewAccessor 似乎只允许存储结构而不是引用类型。

有没有办法存储文件的引用类型使用的内存并从该内存块重建对象（没有二进制序列化）？

问候大家，

我想通过内存映射文件实现 Java 对象的透明持久性（利用 OS 分页/交换机制）。

我的问题是：如何将 Java 对象移动到我的内存映射块？另外，我怎样才能强制一个新的对象实例驻留在这样的块中？

众所周知，内存映射块可以看作是一个字节数组，而我在这里真正要问的是如何将 Java 对象的地址空间与此类数组之一重叠？这样我们仍然可以在操作系统透明地处理持久性（写入脏页）时通过对象操作数据。

如果 Java 不允许我这样做，你会建议我使用哪种跨平台和垃圾收集 OO 语言？

谢谢大家。