深入剖析mmap原理

概述

对于mmap，您是否能从原理上解析以下三个问题：

1. mmap比物理内存+swap空间大情况下，是否有问题？
2. MAP_SHARED，MAP_PRIVATE，MAP_ANONYMOUS，MAP_NORESERVE到底有什么区别?
3. 常听说mmap的读写比传统的系统调用(read, write)快，但真的是这样子吗？原因是什么？

要解决这些疑问，可能还需要在操作系统层面多了解。本文将尝试通过这些问题深入剖析，希望通过这篇文章，能使大家对mmap有较深入的认识，也能在存储引擎的设计中，有所参考。

背景

最近在研发分布式日志存储系统，这是一个基于Raft协议的自研分布式日志存储系统，Logstore则是底层存储引擎。

Logstore中，使用mmap对数据文件进行读写。Logstore的存储结构简化如下图：

logstore mmap.png

Logstore使用了Segments Files + Index Files的方式存储Log，Segment File是存储主体，用于存储Log数据，使用定长的方式，默认每个512M，Index File主要用于Segment File的内容检索。

Logstore使用mmap的方式读写Segment File，Segments Files的个数，主要取决于磁盘空间或者业务需求，一般情况下，Logstore会存储1T~5T的数据。

什么是mmap

我们先看看什么是mmap。

在<<深入理解计算机系统>>这本书中，mmap定义为：Linux通过将一个虚拟内存区域与一个磁盘上的对象(object)关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射(memory mapping)。

在Logstore中，mapping的对象是普通文件(Segment File)。

mmap的原理

mmap在进程虚拟内存做了什么

我们先来简单看一下mapping一个文件，mmap做了什么事情。如下图所示：

map file.png

假设我们mmap的文件是FileA，在调用mmap之后，会在进程的虚拟内存分配地址空间，创建映射关系。

这里值得注意的是，mmap只是在虚拟内存分配了地址空间，举个例子，假设上述的FileA是2G大小

[dragon@xxx.xxx] ls -lat FileA

2147483648 Apr 25 10:22 FileA

在mmap之后，查看mmap所在进程的maps描述，可以看到

[dragon@xxx.xxx] cat maps
....
7f35eea8d000-7f366ea8d000 rw-s 00000000 08:03 13110516 FileA
....

由上可以看到，在mmap之后，进程的地址空间7f35eea8d000-7f366ea8d000被分配，并且map到FileA，7f366ea8d000减去7f35eea8d000，刚好是2147483648(ps: 这里是整个文件做mapping)

mmap在物理内存做了什么

在Linux中，VM系统通过将虚拟内存分割为称作虚拟页(Virtual Page，VP)大小固定的块来处理磁盘(较低层)与上层数据的传输，一般情况下，每个页的大小默认是4096字节。同样的，物理内存也被分割为物理页(Physical Page，PP)，也为4096字节。

上述例子，在mmap之后，如下图：

virtual-physical.png

在mmap之后，并没有在将文件内容加载到物理页上，只上在虚拟内存中分配了地址空间。当进程在访问这段地址时（通过mmap在写入或读取时FileA），若虚拟内存对应的page没有在物理内存中缓存，则产生"缺页"，由内核的缺页异常处理程序处理，将文件对应内容，以页为单位(4096)加载到物理内存，注意是只加载缺页，但也会受操作系统一些调度策略影响，加载的比所需的多，这里就不展开了。
(PS: 再具体一些，进程在访问7f35eea8d000这个进程虚拟地址时，MMU通过查找页表，发现对应内容未缓存在物理内存中，则产生"缺页")

缺页处理后，如下图：

virtual-physical assign.png

mmap的分类

我认为从原理上，mmap有两种类型，一种是有backend，一种是没有backend。

有backend

backend mmap.png

这种模式将普通文件做memory mapping(非MAP_ANONYMOUS)，所以在mmap系统调用时，需要传入文件的fd。这种模式常见的有两个常用的方式，MAP_SHARED与MAP_PRIVATE，但它们的行为却不相同。

1) MAP_SHARED

这个方式我认为可以从两个角度去看：

1. 进程间可见：这个被提及太多，就不展开讨论了
2. 写入/更新数据会回写backend，也就是回写文件：这个是很关键的特性，是在Logstore设计实现时，需要考虑的重点。Logstore的一个基本功能就是不断地写入数据，从实现上看就是不断地mmap文件，往内存写入/更新数据以达到写入文件的目的。但物理内存是有限的，在写入数据超过物理内存时，操作系统会进行页置换，根据淘汰算法，将需要淘汰的页置换成所需的新页，而恰恰因为是有backend的，所以mmap对应的内存是可以被淘汰的（若内存页是"脏"的，则操作系统会先将数据回写磁盘再淘汰）。这样，就算mmap的数据远大于物理内存，操作系统也能很好地处理，不会产生功能上的问题。

2) MAP_PRIVATE

这是一个copy-on-write的映射方式。虽然他也是有backend的，但在写入数据时，他会在物理内存copy一份数据出来(以页为单位)，而且这些数据是不会被回写到文件的。这里就要注意，因为更新的数据是一个副本，而且不会被回写，这就意味着如果程序运行时不主动释放，若更新的数据超过可用物理内存+swap space，就会遇到OOM Killer。

无backend

无backend通常是MAP_ANONYMOUS，就是将一个区域映射到一个匿名文件，匿名文件是由内核创建的。因为没有backend，写入/更新的数据之后，若不主动释放，这些占用的物理内存是不能被释放的，同样会出现OOM Killer。

mmap比内存+swap空间大情况下，是否有问题

到这里，这个问题就比较好解析了。我们可以将此问题分离为：

1. 虚拟内存是否会出问题
2. 物理内存是否会出问题

-- 虚拟内存是否会出问题：

回到上述的"mmap在进程虚拟内存做了什么"，我们知道mmap会在进程的虚拟内存中分配地址空间，比如1G的文件，则分配1G的连续地址空间。那究竟可以maping多少呢？在64位操作系统，寻址范围是2^64 ，除去一些内核、进程数据等地址段之外，基本上可以认为可以mapping无限大的数据(不太严谨的说法)。

-- 物理内存是否会出问题
回到上述"mmap的分类"，对于有backend的mmap，而且是能回写到文件的，映射比内存+swap空间大是没有问题的。但无法回写到文件的，需要非常注意，主动释放。

MAP_NORESERVE

MAP_NORESERVE是mmap的一个参数，MAN的说明是"Do not reserve swap space for this mapping. When swap space is reserved, one has the guarantee that it is possible to modify the mapping."。

我们做个测试：

场景A：物理内存+swap space: 16G，映射文件30G，使用一个进程进行mmap，成功后映射后持续写入数据
场景B：物理内存+swap space: 16G，映射文件15G，使用两个进程进行mmap，成功后映射后持续写入数据

从上述测试可以看出，从现象上看，NORESERVE是绕过mmap的校验，让其可以mmap成功。但其实在RESERVE的情况下(序列4)，从测试结果看，也没有保障。

mmap的性能

mmap的性能经常与系统调用（write/read）做对比。

我们将读写分开看，先尝试从原理上分析两者的差异，然后再通过测试验证。

mmap的写性能

我们先来简单讲讲write系统调用写文件的过程：

write process.png

1. Step1：进程(用户态)调用write系统调用，并告诉内核需要写入数据的开始地址与长度（告诉内核写入的数据在哪）。
2. Step2：内核write方法，将校验用户态的数据，然后复制到kernel buffer（这里是Page Cache）。
   [ ps: 特意查了ext4 write的内核实现，write是直接将user buffer copy到page中 ]
3. Step3: 由操作系统调用，将脏页回写到磁盘（通常这是异步的）