【深入浅出Linux】关于mmap的解析

看这篇文章之前需要知道一个概念

虚拟内存系统通过将虚拟内存分割为称作虚拟页(Virtual Page，VP)大小固定的块，一般情况下，每个虚拟页的大小默认是4096字节。同样的，物理内存也被分割为物理页(Physical Page，PP)，也为4096字节。

在LINUX中我们可以使用mmap用来在进程虚拟内存地址空间中分配地址空间，创建和物理内存的映射关系。

映射关系可以分为两种

1、文件映射

磁盘文件映射进程的虚拟地址空间，使用文件内容初始化物理内存。

2、匿名映射

初始化全为0的内存空间。

而对于映射关系是否共享又分为

1、私有映射(MAP_PRIVATE)

多进程间数据共享，修改不反应到磁盘实际文件，是一个copy-on-write（写时复制）的映射方式。

2、共享映射(MAP_SHARED)

多进程间数据共享，修改反应到磁盘实际文件中。

因此总结起来有4种组合

1、私有文件映射

多个进程使圆御用同样的物理内存页进行初始化，但是各个进程对内存文件的修改不会共享，也不会反应到物理文件中

2、私有匿名映射

mmap会创建一个新的映射，各个进程不共享，这种使用主要用于分配内存(malloc分配大内存会调告腔基用mmap)。

例如开辟新进程时，会为每个进程分配虚拟的地址空间，这些虚拟地址映射的物理内存空间各个进程间读的时候共享，写的时候会copy-on-write。

3、共享文件映射

多个进程通过虚拟内存技术共享同样的物理内存空间，对内存文件 的修改会反应到实际物理文件中，他也是进程间通信(IPC)的一种机制。

4、共享匿名映射

这种机制在进行fork的时候不会采用写时复制，父子进程完全共享同样的物理内存页，这也就实现了父子进程通信(IPC).

这里值得注意的是，mmap只是在虚拟内存分配了地址空间，只有在第一次访问虚拟内存的时候才分配物理内存。

在mmap之后，并没有在将文件内容加载到物理页上，只上在虚拟内存中分配了地址空间。当进程在访问这段地址时，通过查找页表，发现虚拟内存对应的页没有在物理内存中缓存，则产生"缺页"，由内核的缺页异常处理程序处理，将文件对应内容，以页为单位(4096)加载到物理内存，注意是只加载缺页，但也会受 *** 作系统一些调度策略影响，加载的比所需的多。

1.write

因为物理内存是有限的，mmap在写入数据超过物理内存时， *** 作系统会进行页置换，根据淘汰算法，将需要淘汰的页置换成所需的新页，所以mmap对应的内存是可以被淘汰的（若内存页是"脏"的，则 *** 作系统会先将数据回写磁盘再淘汰）。这样，就算mmap的数据远大于物理内存， *** 作系统也能很好地处理，不会产生功能上的问题。

2.read

从图中可以看出，mmap要比普通的read系统调用少了一次copy的过程。因为read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。

测试结果来源于： 深入剖析mmap-从三个关键问题说起

1.读性能分析

场景：对2G的文件进行顺序写入

可以看到mmap在100byte写入时已袜谨经基本达到最大写入性能，而write调用需要在4096(也就是一个page size)时，才能达到最大写入性能。

从测试结果可以看出，在写小数据时，mmap会比write调用快，但在写大数据时，反而没那么快。

2.写性能分析

场景：对2G的文件进行顺序读取（为了避免磁盘对测试的影响，2G文件都缓存在pagecache中）

由上可以看出，在read上面，mmap的性能还是非常好的。

优点如下：

1、对文件的读取 *** 作跨过了页缓存，减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率。

2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改 *** 作可以直接反映在映射的区域内，从而被对方空间及时捕捉。

3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的。同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据。

4、可用于实现高效的大规模数据传输。内存空间不足，是制约大数据 *** 作的一个方面，解决方案往往是借助硬盘空间协助 *** 作，补充内存的不足。但是进一步会造成大量的文件I/O *** 作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效。

缺点如下:

1.文件如果很小，是小于4096字节的，比如10字节，由于内存的最小粒度是页，而进程虚拟地址空间和内存的映射也是以页为单位。虽然被映射的文件只有10字节，但是对应到进程虚拟地址区域的大小需要满足整页大小，因此mmap函数执行后，实际映射到虚拟内存区域的是4096个字节，11~4096的字节部分用零填充。因此如果连续mmap小文件，会浪费内存空间。

3.如果更新文件的 *** 作很多，会触发大量的脏页回写及由此引发的随机IO上。所以在随机写很多的情况下，mmap方式在效率上不一定会比带缓冲区的一般写快。

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

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

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

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

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定义为：Linux通过将一个虚拟内存区域与一个磁盘上的对象(object)关联起来，以初始化这个虚拟内存区域的内容，这个过程称为内存映射(memory mapping)。

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

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

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

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

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

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

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

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

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

(PS: 再具体一些，进程在访问7f35eea8d000这个进程虚拟地址时，MMU通过查找页表，发现对应内容未缓存在物理内亩羡存中，则产生"缺页")

缺页处理后，如下图：

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

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

1) MAP_SHARED

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

2) MAP_PRIVATE

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

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

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

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

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

-- 物理内存是否会出问题

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

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的性能经常与系统调用（write/read）做对比。

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

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

再来简单讲讲使用mmap时，写入文件流程：

系统调用会对性能有影响，那么从理论上分析:

下面我们对两者进行性能测试：

场景：对2G的文件进行顺序写入(go语言编写)

每次写入大小 | mmap 耗时 | write 耗时

--------------- | ------- | -------- | --------

| 1 byte | 22.14s | >300s

| 100 bytes | 2.84s | 22.86s

| 512 bytes | 2.51s | 5.43s

| 1024 bytes | 2.48s | 3.48s

| 2048 bytes | 2.47s | 2.34s

| 4096 bytes | 2.48s | 1.74s

| 8192 bytes | 2.45s | 1.67s

| 10240 bytes | 2.49s | 1.65s

可以看到mmap在100byte写入时已经基本达到最大写入性能，而write调用需要在4096(也就是一个page size)时，才能达到最大写入性能。

从测试结果可以看出，在写小数据时，mmap会比write调用快，但在写大数据时，反而没那么快(但不太确认是否go的slice copy的性能问题，没时间去测C了)。

测试结果与理论推导吻合。

我们还是来简单分析read调用与mmap的流程：

从图中可以看出，read调用确实比mmap多一次copy。因为read调用，进程是无法直接访问kernel space的，所以在read系统调用返回前，内核需要将数据从内核复制到进程指定的buffer。但mmap之后，进程可以直接访问mmap的数据(page cache)。

从原理上看，read性能会比mmap慢。

接下来实测一下性能区别：

场景：对2G的文件进行顺序读取(go语言编写)

(ps: 为了避免磁盘对测试的影响，我让2G文件都缓存在pagecache中)

每次读取大小 | mmap 耗时 | write 耗时

--------------- | ------- | -------- | --------

| 1 byte | 8215.4ms | >300s

| 100 bytes | 86.4ms | 8100.9ms

| 512 bytes | 16.14ms | 1851.45ms

| 1024 bytes | 8.11ms | 992.71ms

| 2048 bytes | 4.09ms | 636.85ms

| 4096 bytes | 2.07ms | 558.10ms

| 8192 bytes | 1.06ms | 444.83ms

| 10240 bytes | 867.88µs | 475.28ms

由上可以看出，在read上面，mmap比write的性能差别还是很大的。测试结果与理论推导吻合。

对mmap的深入了解，能帮助我们在设计存储系统时，更好地进行决策。

比如，假设需要设计一个底层的数据结构是B+ Tree，node *** 作以Page单位的单机存储引擎，根据上述推论，写入使用系统调用，而读取使用mmap，可以达到最优的性能。而LMDB就是如此实现的。

mmap：是MindManager导图默认的官方保存格式，也是使用最多的保存格式。

MindManager作为专业实用性软件，和其他的软件有很好的兼容性，从MindManager的导出格式上就可以看出来，MindManager支持15种导出格式，完全满足用户的所有需求，本教程将主讲MindManager思维导图的导出格式。

MindManager 2019 win版 : 点击免费获取MindManager 2019下载地址

MindManager 11 Mac版 : 点击免费获取MindManager 下载地址

打开MindManager思维导图软件，制作好导图。点击文件→另存为。在文件另存为对话框内点击保存类型右边的倒置三角，即可打开导图的保存格式列表。

mmap：是MindManager导图默认的官方保存格式，也是使用最多的保存格式。

xmmap、xml：是另一种MindManager导图的保存格式。

mmat、xmmat：是橡迹MindManager模板较常用的保存格式。

ppt、pot：是将MindManager导图保存为PPT格式，方便文稿演示。

docx、dotx、doc、dot：是将MindManager导图保存为Word文档，便于存储。

pdf：是将MindManager导图保存为PDF文件，PDF是交互式只读文件，便于查阅。

swf：是将MindManager导图保存为swf格式，便于插入到网页和在Flash浏览器中查看。卖如消

jpeg、jpg：是将MindManager导图保存为图片的格式。

以上格式是MindManager最常见的导出格式，其他的格式需要中知专业的软件才能打开，用户使用的也比较少，在此不作详解。

---