mmap 可能会让 Go 程序更慢（译）

2023-02-26 01:56:02Python018

mmap 可能会让 Go 程序更慢（译）,第1张

你有在 Go 程序中使用 syscall.Mmap 吗？答案很可能是肯定的，只是你不知道而已。因为你的程序直接或间接的依赖包会使用 syscall.Mmap，毕竟众所周知的：mmap 要比常规的 I/O 操作快。我们现在来看一下到底是不是这样。

mmap 是一个系统调用，将文件内容直接映射到内存地址空间。mmap 之后，你就可以像访问内存一样对文件内容进行读写。这样就不需要使用比较重的系统调用去对文件内容进行读写了。

使用系统调用操作文件，进程会在内核态和用户态之间频繁切换，而且数据还要在用户态和内核态之间来回拷贝。而 mmap 后，整个数据的读写都在用户态完成，不会进入内核态，同时也少了一次数据拷贝。是不是觉得很完美？其实不是的。

程序访问 mmap 返回的内存地址空间会发生什么？有两种场景：

你可能会说，那正常的使用 read/write 访问冷数据，也会有同样的问题；也会触发缺页中断，唯一不同的是把内存访问换成了一个系统调用。

的确是这样，但是让我们来看一下 Go 的运行时机制。

Go 的 goroutine 是运行在 OS threads（操作系统线程）之上的。最多可以有 GOMAXPROCS 个 goroutine 并行的运行在 OS thread 上。其他就绪的 goroutine 会一直等待，直到运行中的 goroutine 发生了阻塞、出让、或者系统调用。goroutine 会因为 I/O、channel、mutex 而阻塞，会因为函数调用、内存分配、调用 runtime.Gosched 而出让。 Goroutine 并不会因为缺页中断而阻塞！

再强调一次，goroutine 不会因为缺页中断而发生阻塞或出让，因为它对 Go 运行时是不可见的。 那当一个 goroutine 通过 mmap 访问到冷数据时，会发生什么呢？它会让你的程序卡在那里很长很长时间。在这期间，它还是会持续占用你的 OS thread，所以其他就绪的 goroutine 因为受到 GOMAXPROCS 的限制，只能排队。这就导致 CPU 的利用率很低。如果 GOMAXPROCS 个 goroutine 同时访问 mmap 文件的冷数据，会发生什么？整个程序会彻底地 Hang 住，直到 OS 完成了这些 goroutine 触发的缺页中断。

监控请求延迟和 CPU 利用率：

这些程序在程序访问 page cache 中的数据时，是没有任何问题的。page cache 的大小受内存大小限制。所以这些程序只有在被 mmap 的文件很大时（超出内存大小），才会出现卡住的现象。在低负载场景，或者存储设备较快时（比如 SSD），不太容易注意到程序出现卡顿。

当 mmap 文件小于内存空间时，以下场景也会出现卡顿：

尽量避免在 Go 程序中使用 mmap，因为它可能让你的程序 Hang 住。

mmap函数的使用方法 UNIX网络编程第二卷进程间通信对mmap函数进行了说明。该函数主要用途有三个：

1、将一个普通文件映射到内存中，通常在需要对文件进行频繁读写时使用，这样用内存读写取代I/O读写，以获得较高的性能；

2、将特殊文件进行匿名内存映射，可以为关联进程提供共享内存空间；

3、为无关联的进程提供共享内存空间，一般也是将一个普通文件映射到内存中。

函数：void *mmap(void *start,size_t length,int prot,int flags,int fd,off_t offsize)

参数start：指向欲映射的内存起始地址，通常设为 NULL，代表让系统自动选定地址，映射成功后返回该地址。

参数length：代表将文件中多大的部分映射到内存。

参数prot：映射区域的保护方式。可以为以下几种方式的组合：

PROT_EXEC 映射区域可被执行

PROT_READ 映射区域可被读取

PROT_WRITE 映射区域可被写入

PROT_NONE 映射区域不能存取

参数flags：影响映射区域的各种特性。在调用mmap()时必须要指定MAP_SHARED 或MAP_PRIVATE。

MAP_FIXED 如果参数start所指的地址无法成功建立映射时，则放弃映射，不对地址做修正。通常不鼓励用此旗标。

MAP_SHARED对映射区域的写入数据会复制回文件内，而且允许其他映射该文件的进程共享。

MAP_PRIVATE 对映射区域的写入操作会产生一个映射文件的复制，即私人的“写入时复制”（copy on write）对此区域作的任何修改都不会写回原来的文件内容。

MAP_ANONYMOUS建立匿名映射。此时会忽略参数fd，不涉及文件，而且映射区域无法和其他进程共享。

MAP_DENYWRITE只允许对映射区域的写入操作，其他对文件直接写入的操作将会被拒绝。

MAP_LOCKED 将映射区域锁定住，这表示该区域不会被置换（swap）。

参数fd：要映射到内存中的文件描述符。如果使用匿名内存映射时，即flags中设置了MAP_ANONYMOUS，fd设为-1。有些系统不支持匿名内存映射，则可以使用fopen打开/dev/zero文件，然后对该文件进行映射，可以同样达到匿名内存映射的效果。

参数offset：文件映射的偏移量，通常设置为0，代表从文件最前方开始对应，offset必须是分页大小的整数倍。

返回值：

若映射成功则返回映射区的内存起始地址，否则返回MAP_FAILED(－1)，错误原因存于errno 中。

错误代码：

EBADF 参数fd 不是有效的文件描述词

EACCES 存取权限有误。如果是MAP_PRIVATE 情况下文件必须可读，使用MAP_SHARED则要有PROT_WRITE以及该文件要能写入。

EINVAL 参数start、length 或offset有一个不合法。

EAGAIN 文件被锁住，或是有太多内存被锁住。

ENOMEM 内存不足。

系统调用mmap()用于共享内存的两种方式：

（1）使用普通文件提供的内存映射：

适用于任何进程之间。此时，需要打开或创建一个文件，然后再调用mmap()

典型调用代码如下：

fd=open(name, flag, mode)if(fd<0) ...

ptr=mmap(NULL, len , PROT_READ|PROT_WRITE, MAP_SHARED , fd , 0)

通过mmap()实现共享内存的通信方式有许多特点和要注意的地方，可以参看UNIX网络编程第二卷。

（2）使用特殊文件提供匿名内存映射：

适用于具有亲缘关系的进程之间。由于父子进程特殊的亲缘关系，在父进程中先调用mmap()，然后调用 fork()。那么在调用fork()之后，子进程继承父进程匿名映射后的地址空间，同样也继承mmap()返回的地址，这样，父子进程就可以通过映射区域进行通信了。注意，这里不是一般的继承关系。一般来说，子进程单独维护从父进程继承下来的一些变量。而mmap()返回的地址，却由父子进程共同维护。对于具有亲缘关系的进程实现共享内存最好的方式应该是采用匿名内存映射的方式。此时，不必指定具体的文件，只要设置相应的标志即可。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/scorpio16/archive/2008/01/22/2059623.aspx

对于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 耗时