标签 mmap 下的文章

图解Go内存分配器

本文翻译自《A visual guide to Go Memory Allocator from scratch (Golang)》

当我刚开始尝试了解Go的内存分配器时,我发现这真是一件可以令人发疯的事情,因为所有事情似乎都像一个神秘的黑盒(让我无从下手)。由于几乎所有技术魔法都隐藏在抽象之下,因此您需要逐一剥离这些抽象层才能理解它们。

在这篇文章中,我们就来这么做(剥离抽象层去了解隐藏在其下面的技术魔法)。如果您想了解有关Go内存分配器的知识,那么本篇文章正适合您。

一. 物理内存(Physical Memory)和虚拟内存(Virtual Memory)

每个内存分配器都需要使用由底层操作系统管理的虚拟内存空间(Virtual Memory Space)。让我们看看它是如何工作的吧。

img{512x368}

物理存储单元的简单图示(不精确的表示)

单个存储单元(工作流程)的简要介绍:

  1. 地址线(address line, 作为开关的晶体管)提供了访问电容器的入口(数据到数据线(data line))。
  2. 当地址线中有电流流动时(显示为红色),数据线可能会写入电容器,因此电容器已充电,并且存储的逻辑值为“1”。
  3. 当地址线没有电流流动(显示为绿色)时,数据线可能不会写入电容器,因此电容器未充电,并且存储的逻辑值为“0”。
  4. 当处理器(CPU)需要从内存(RAM)中“读取”一个值时,会沿着“地址线”发送电流(关闭开关)。如果电容器保持电荷,则电流流经“ DATA LINE”(数据线)得到的值为1;否则,没有电流流过数据线,电容器将保持未充电状态,得到的值为0。

img{512x368}

物理内存单元如何与CPU交互的简单说明

数据总线(Data Bus):用于在CPU和物理内存之间传输数据。

让我们讨论一下地址线(Address Line)和可寻址字节(Addressable Bytes)。

img{512x368}

CPU和物理内存之间的地址线的表示

  1. DRAM中的每个“字节(BYTE)”都被分配有唯一的数字标识符(地址)。 但“物理字节的表示 != 地址线的数量”。(例如:16位Intel 8088,PAE)
  2. 每条“地址线”都可以发送1bit值,因此它可以表示给定字节地址中指定“bit”。
  3. 在图中,我们有32条地址线。因此,每个可寻址字节都将拥有一个“32bit”的地址。
[ 00000000000000000000000000000000 ] — 低内存地址
[ 11111111111111111111111111111111 ] — 高内存地址

4.由于每个字节都有一个32bit地址,所以我们的地址空间由2的32次方个可寻址字节(即4GB)组成。

因此,可寻址字节取决于地址线的总量,对于64位地址线(x86–64 CPU),其可寻址字节为2的64次方个,但是大多数使用64位指针的体系结构实际上使用48位地址线(AMD64 )和42位地址线(英特尔),理论上支持256TB的物理RAM(Linux 在x86–64上每个进程支持128TB以及4级页表(page table)和Windows每个进程则支持192TB)

由于实际物理内存的限制,因此每个进程都在其自己的内存沙箱中运行-“虚拟地址空间”,即虚拟内存

该虚拟地址空间中字节的地址不再与处理器在地址总线上放置的地址相同。因此,必须建立转换数据结构和系统,以将虚拟地址空间中的字节映射到物理内存地址上的字节。

虚拟地址长什么样呢?

img{512x368}

虚拟地址空间表示

因此,当CPU执行引用内存地址的指令时。第一步是将VMA(virtual memory address)中的逻辑地址转换为线性地址(liner address)。这个翻译工作由内存管理单元MMU(Memory Management Unit)完成。

img{512x368}

这不是物理图,仅是描述。为了简化,不包括地址翻译过程

由于此逻辑地址太大而无法单独管理(取决于各种因素),因此将通过页(page)对其进行管理。当必要的分页构造被激活后,虚拟内存空间将被划分为称为页的较小区域(大多数OS上页大小为4KB,可以更改)。它是虚拟内存中用于内存管理的最小单位。虚拟内存不存储任何内容,仅简单地将程序的地址空间映射到真实的物理内存空间上。

单个进程仅将VMA(虚拟内存地址)视为其地址。这样,当我们的程序请求更多“堆内存(heap memory)”时会发生什么呢?

img{512x368}

一段简单的用户请求更多堆内存的汇编代码

img{512x368}

增加堆内存

程序通过brk(sbrk/mmap等)系统调用请求更多内存。但内核实际上仅是更新了堆的VMA。

注意:此时,实际上并没有分配任何页帧,并且新页面也没有在物理内存存在。这也是VSZ与RSS之间的差异点。

二. 内存分配器

有了“虚拟地址空间”的基本概述以及堆内存增加的理解之后,内存分配器现在变得更容易说明了。

如果堆中有足够的空间来满足我们代码中的内存请求,则内存分配器可以在内核不参与的情况下满足该请求,否则它会通过系统调用brk扩大堆,通常会请求大量内存。(默认情况下,对于malloc而言,大量的意思是 > MMAP_THRESHOLD字节-128kB)。

但是,内存分配器的责任不仅仅是更新brk地址。其中一个主要的工作则是如何的降低内外部的内存碎片以及如何快速分配内存块。考虑按p1~p4的顺序,先使用函数malloc在程序中请求连续内存块,然后使用函数free(pointer)释放内存。

img{512x368}

外部内存碎片演示

在第4步,即使我们有足够的内存块,我们也无法满足对6个连续内存块分配的请求,从而导致内存碎片。

那么如何减少内存碎片呢?这个问题的答案取决于底层库使用的特定的内存分配算法。

我们将研究TCMalloc内存分配器,Go内存分配器采用的就是该内存分配器模型。

三. TCMalloc

TCMalloc(thread cache malloc)的核心思想是将内存划分为多个级别,以减少锁的粒度。在TCMalloc内部,内存管理分为两部分:线程内存和页堆(page heap)。

线程内存(thread memory)

每个内存页分为多级固定大小的“空闲列表”,这有助于减少碎片。因此,每个线程都会有一个无锁的小对象缓存,这使得在并行程序下分配小对象(<= 32k)非常高效。

img{512x368}

线程缓存(每个线程拥有此线程本地线程缓存)

页堆(page heap)

TCMalloc管理的堆由页集合组成,其中一组连续页的集合可以用span表示。当分配的对象大于32K时,将使用页堆进行分配。

img{512x368}

页堆(用于span管理)

如果没有足够的内存来分配小对象,内存分配器就会转到页堆以获取内存。如果还没有足够的内存,页堆将从操作系统中请求更多内存。

由于这种分配模型维护了一个用户空间的内存池,因此极大地提高了内存分配和释放的效率。

注意:尽管go内存分配器最初是基于tcmalloc的,但是现在已经有了很大的不同。

四. Go内存分配器

我们知道Go运行时会将Goroutines(G)调度到逻辑处理器(P)上执行。同样,基于TCMalloc模型的Go还将内存页分为67个不同大小级别。

如果您不熟悉Go调度程序,则可以在这里获取关于Go调度程序的相关知识。

img{512x368}

Go中的内存块的大小级别

Go默认采用8192B大小的页。如果这个页被分成大小为1KB的块,我们一共将拿到8块这样的页:

img{512x368}

将8 KB页面划分为1KB的大小等级(在Go中,页的粒度保持为8KB)

Go中的这些页面运行也通过称为mspan的结构进行管理。

选择要分配给每个尺寸级别的尺寸类别和页面计数(将页面数分成给定尺寸的对象),以便将分配请求圆整(四舍五入)到下一个尺寸级别最多浪费12.5%

mspan

简而言之,它是一个双向链表对象,其中包含页面的起始地址,它具有的页面的span类以及它包含的页面数。

img{512x368}

Go内存分配器中mspan的表示形式

mcache

与TCMalloc一样,Go为每个逻辑处理器(P)提供了一个称为mcache的本地内存线程缓存,因此,如果Goroutine需要内存,它可以直接从mcache中获取它而无需任何锁,因为在任何时间点只有一个Goroutine在逻辑处理器(P)上运行。

mcache包含所有级别大小的mspan作为缓存。

img{512x368}

Go中P,mcache和mspan之间的关系

由于每个P拥有一个mcache,因此从mcache进行分配时无需加锁。

对于每个级别,都有两种类型。
* scan —包含指针的对象。
* noscan —不包含指针的对象。

这种方法的好处之一是在进行垃圾收集时,GC无需遍历noscan对象。

什么Go mcache?

对象大小<= 32K字节的分配将直接交给mcache,后者将使用对应大小级别的mspan应对

当mcache没有可用插槽(slot)时会发生什么?

从mcentral mspan list中获取一个对应大小级别的新的mspan。

mcentral

mcentral对象集合了所有给定大小级别的span,每个mcentral是两个mspan列表。

  1. 空的mspanList — 没有空闲内存的mspan或缓存在mcache中的mspan的列表
  2. 非空mspanList – 仍有空闲内存的span列表。

当从mcentral请求新的Span时,它将从非空mspanList列表中获取(如果可用)。这两个列表之间的关系如下:当请求新的span时,该请求从非空列表中得到满足,并且该span被放入空列表中。释放span后,将根据span中空闲对象的数量将其放回非空列表。

img{512x368}

mcentral表示

每个mcentral结构都在mheap中维护。

mheap

mheap是在Go中管理堆的对象,且只有一个全局mheap对象。它拥有虚拟地址空间。

img{512x368}

mheap的表示

从上图可以看出,mheap具有一个mcentral数组。此数组包含每个大小级别span的mcentral。

central [numSpanClasses]struct {
      mcentral mcentral
        pad      [sys.CacheLineSize unsafe.Sizeof(mcentral{})%sys.CacheLineSize]byte
}

由于我们对每个级别的span都有mcentral,因此当mcache从mcentral请求一个mspan时,仅涉及单个mcentral级别的锁,因此其他mache的不同级别mspan的请求也可以同时被处理。

padding确保将MCentrals以CacheLineSize字节间隔开,以便每个MCentral.lock获得自己的缓存行,以避免错误的共享问题。

那么,当该mcentral列表为空时会发生什么?mcentral将从mheap获取页以用于所需大小级别span的分配。

  • free [_MaxMHeapList]mSpanList:这是一个spanList数组。每个spanList中的mspan由1〜127(_MaxMHeapList-1)页组成。例如,free[3]是包含3个页面的mspan的链接列表。Free表示空闲列表,即尚未进行对象分配。它对应于忙碌列表(busy list)。

  • freelarge mSpanList:mspans列表。每个mspan的页数大于127。Go内存分配器以mtreap数据结构来维护它。对应busyLarge。

大小> 32k的对象是一个大对象,直接从mheap分配。这些较大的请求需要中央锁(central lock),因此在任何给定的时间点只能满足一个P的请求

五. 对象分配流程

  • 大小> 32k是一个大对象,直接从mheap分配。
  • 大小<16B,使用mcache的tiny分配器分配
  • 大小在16B〜32k之间,计算要使用的sizeClass,然后在mcache中使用相应的sizeClass的块分配
  • 如果与mcache对应的sizeClass没有可用的块,则向mcentral发起请求。
  • 如果mcentral也没有可用的块,则向mheap请求。mheap使用BestFit查找最合适的mspan。如果超出了申请的大小,则会根据需要进行划分,以返回用户所需的页面数。其余页面构成一个新的mspan,并返回mheap空闲列表。
  • 如果mheap没有可用的span,请向操作系统申请一组新的页(至少1MB)。

但是Go在OS级别分配的页面甚至更大(称为arena)。分配大量页面将分摊与操作系统进行对话的成本。

所有请求的堆内存都来自于arena。让我们看看arena是什么。

六. Go虚拟内存

让我们看一个简单go程序的内存。

func main(){
    for {}
}

img{512x368}

程序的进程状态

因此,即使是简单的go程序,占用的虚拟空间也是大约100MB而RSS只有696kB。让我们尝试首先找出这种差异的原因。

img{512x368}

map和smap统计信息

因此,内存区域的大小约为〜2MB, 64MB and 32MB。这些是什么?

Arena

原来,Go中的虚拟内存布局由一组arena组成。初始堆映射是一个arena,即64MB(基于go 1.11.5)。

img{512x368}

当前在不同系统上的arena大小。

因此,当前根据程序需要,内存以较小的增量进行映射,并且它以一个arena(〜64MB)开始。

这是可变的。早期的go保留连续的虚拟地址,在64位系统上,arena大小为512 GB。(如果分配足够大并且被mmap拒绝,会发生什么?)

这个arena集合是我们所谓的堆。Go以8192B大小粒度的页面管理每个arena。

img{512x368}

单个arena(64 MB)。

Go还有两个span和bitmap块。它们都在堆外分配,并存储着每个arena的元数据。它主要在垃圾收集期间使用(因此我们现在将其保留)。

我们刚刚讨论过的Go中的内存分配策略,但这些也仅是奇妙多样的内存分配的一些皮毛。

但是,Go内存管理的总体思路是使用不同的内存结构为不同大小的对象使用不同的缓存级别内存来分配内存。将从操作系统接收的单个连续地址块分割为多级缓存以减少锁的使用,从而提高内存分配效率,然后根据指定的大小分配内存分配,从而减少内存碎片,并在内存释放houhou有利于更快的GC。

现在,我将向您提供此Go Memory Allocator的全景图。

img{512x368}

运行时内存分配器的可视化全景图。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

探讨docker容器对共享内存的支持情况

我们的遗留系统广泛使用了性能最佳的IPC方式 – 共享内存,而且用到了两种共享内存的实现方式:System V共享内存(shmget、shmat、shmdt)以及Mmap映射Regular File。System V共享内存支持一定程度上的内存数据持久化,即当程序创建共享内存对象后,如果不显式删除或物理主机重启,该IPC对象会一直保留,其中的数据也不会丢 失;mmap映射Regular File的方式支持内存数据持久化到文件中,即便物理主机重启,这部分数据依旧不会丢失,除非显式删除文件。这两个共享内存机制,尤其是其持久化的特性是 我们的系统所依赖的。但是在Docker容器中,这两种共享内存机制依旧能被很好的支持吗?我们通过试验来分析一下。

一、System V共享内存

一个启动的Docker容器就是一个拥有了自己的内核名字空间的进程,其pid、net、ipc、mnt、uts、user等均与其他进程隔离,对于运行于该容器内的程序而言,它仿佛会觉得它独占了一台“主机”。对于这类“主机”,我们首先来测试一下其中的system v共享内存是否依旧能像物理主机上一样,在程序退出后依旧能保持持久化?在容器退出后能保持么?

我们先来写两个测试程序,一个用于创建system v共享内存,并写入一些数据,另外一个程序则映射该共享内存并尝试读出内存中的数据。由于Golang目前仍未提供对System V共享内存的高级封装接口,通过syscall包的Syscall调用又太繁琐,因此我们直接使用C代码与Go代码结合的方式实现这两个测试程序。之前写 过一篇名为《Go与C语言互操作》的博文,看不懂下面代码的朋友,可以先阅读一下这篇文章。

//systemv_shm_wr.go
package main

//#include <sys/types.h>
//#include <sys/ipc.h>
//#include <sys/shm.h>
//#include <stdio.h>
//
//#define SHMSZ     27
//
//int shm_wr() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, IPC_CREAT | 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//    for (c = 'a'; c <= 'z'; c++)
//        *s++ = c;
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Write Ok")
}

//systemv_shm_rd.go

package main

//#include <sys/types.h>
//#include <sys/ipc.h>
//#include <sys/shm.h>
//#include <stdio.h>
//
//#define SHMSZ     27
//
//int shm_rd() {
//    char c;
//    int shmid;
//    key_t key;
//    char *shm, *s;
//
//    key = 5678;
//
//    if ((shmid = shmget(key, SHMSZ, 0666)) < 0) {
//        return -1;
//    }
//
//    if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) {
//        return -2;
//    }
//
//    s = shm;
//
//    int i = 0;
//    for (i = 0; i < SHMSZ-1; i++)
//        printf("%c ", *(s+i));
//    printf("\n");
//    s = NULL;
//
//    return 0;
//}
import "C"

import "fmt"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("SystemV Share Memory Create and Read Error:", i)
                return
        }
        fmt.Println("SystemV Share Memory Create and Read Ok")
}

我们通过go build构建上面两个程序,得到两个测试用可执行程序:systemv_shm_wr和systemv_shm_rd。下面我们来构建我们的测试用docker image,Dockerfile内容如下:

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./systemv_shm_wr /bin/
COPY ./systemv_shm_rd /bin/

构建Docker image:“shmemtest:v1”:

$ sudo docker build -t="shmemtest:v1" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./systemv_shm_wr /bin/
 —> ea59fb767573
Removing intermediate container 4ce91720897b
Step 3 : COPY ./systemv_shm_rd /bin/
 —> 1ceb207b1009
Removing intermediate container 7ace7ad53a3f
Successfully built 1ceb207b1009

启动一个基于该image的容器:
$ sudo docker run -it "shmemtest:v1" /bin/bash

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
0a2f37bee6eb        shmemtest:v1        "/bin/bash"         28 seconds ago      Up 28 seconds                           elegant_hawking

进入容器,先后执行systemv_shm_wr和systemv_shm_rd,我们得到如下结果:

bash-4.1# systemv_shm_wr
SystemV Share Memory Create and Write Ok
bash-4.1# systemv_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
SystemV Share Memory Create and Read Ok

在容器运行过程中,SystemV共享内存对象是可以持久化的。systemv_shm_wr退出后,数据依旧得以保留。我们接下来尝试一下重启container后是否还能读出数据:

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
0a2f37bee6eb        shmemtest:v1        "/bin/bash"         8 minutes ago       Up 8 minutes                            elegant_hawking    
$ sudo docker stop 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker start 0a2f37bee6eb
0a2f37bee6eb
$ sudo docker attach 0a2f37bee6eb
bash-4.1# systemv_shm_rd
SystemV Share Memory Create and Read Error: -1

程序返回-1,显然在shmget时就出错了,系统已经没有了key为"5678"的这个共享内存IPC对象了。也就是说当容器stop时,就好比我们的物理主机关机,docker将该容器对应的共享内存IPC对象删除了。

从原理上分析,似乎我们也能得出此结论:毕竟Docker container是通过kernel namespace隔离的,容器中的进程在IPC资源申请时需要加入namespace信息。打个比方,如果我们启动容器的进程pid(物理主机视角)是 1234,那么这容器内进程申请的共享内存IPC资源(比如key=5678)的标识应该类似于“1234:5678”这样的形式。重启容器 后,Docker Daemon无法给该容器分配与上次启动相同的pid,因此pid发生了变化,之前容器中的"1234:5678"保留下来也是毫无意义的,还无端占用系 统资源。因此,System V IPC在Docker容器中的运用与物理机有不同,这方面要小心,目前似乎没有很好的方法,也许以后Docker会加入全局IPC,这个我们只能等待。

二、Mmap映射共享内存

接下来我们探讨mmap共享内存在容器中的支持情况。mmap常见的有两类共享内存映射方式,一种映射到/dev/zero,另外一种则是映射到 Regular Fiile。前者在程序退出后数据自动释放,后者则保留在映射的文件中。后者对我们更有意义,这次测试的也是后者。

同样,我们也先来编写两个测试程序。

//mmap_shm_wr.go
package main

//#include <stdio.h>
//#include <sys/types.h>
//#include <sys/mman.h>
//#include <fcntl.h>
//
//#define SHMSZ     27
//
//int shm_wr()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDWR|O_CREAT, S_IRUSR|S_IWUSR)) == -1)  {
//              return -1;
//      }
//
//      lseek(fd, 500, SEEK_CUR);
//      write(fd, "\0", 1);
//      lseek(fd, 0, SEEK_SET);
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//
//      }
//
//      close(fd);
//      s = shm;
//      for (c = 'a'; c <= 'z'; c++) {
//              *(s+(int)(c – 'a')) = c;
//      }
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_wr()
        if i != 0 {
                fmt.Println("Mmap Share Memory Create and Write Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Create and Write Ok")
}

//mmap_shm_rd.go
package main

//#include <stdio.h>
//#include <sys/types.h>
//#include <sys/mman.h>
//#include <fcntl.h>
//
//#define SHMSZ     27
//
//int shm_rd()
//{
//      char c;
//      char *shm = NULL;
//      char *s = NULL;
//      int fd;
//      if ((fd = open("./shm.txt", O_RDONLY)) == -1)  {
//              return -1;
//      }
//
//      shm = (char*)mmap(shm, SHMSZ, PROT_READ, MAP_SHARED, fd, 0);
//      if (!shm) {
//              return -2;
//      }
//
//      close(fd);
//      s = shm;
//      int i = 0;
//      for (i = 0; i < SHMSZ – 1; i++) {
//              printf("%c ", *(s + i));
//      }
//      printf("\n");
//
//      return 0;
//}
import "C"

import "fmt"

func main() {
        i := C.shm_rd()
        if i != 0 {
                fmt.Println("Mmap Share Memory Read Error:", i)
                return
        }
        fmt.Println("Mmap Share Memory Read Ok")
}

我们通过go build构建上面两个程序,得到两个测试用可执行程序:mmap_shm_wr和mmap_shm_rd。下面我们来构建我们的测试用docker image,Dockerfile内容如下:

FROM centos:centos6
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
COPY ./mmap_shm_wr /bin/
COPY ./mmap_shm_rd /bin/

构建Docker image:“shmemtest:v2”:

$ sudo docker build -t="shmemtest:v2" ./
Sending build context to Docker daemon 16.81 MB
Sending build context to Docker daemon
Step 0 : FROM centos:centos6
 —> 68edf809afe7
Step 1 : MAINTAINER Tony Bai <bigwhite.cn@gmail.com>
 —> Using cache
 —> c617b456934a
Step 2 : COPY ./mmap_shm_wr /bin/
 —> Using cache
 —> 01e2f6bc7606
Step 3 : COPY ./mmap_shm_rd /bin/
 —> 0de95503c851
Removing intermediate container 0c472e92809f
Successfully built 0de95503c851

启动一个基于该image的容器:
$ sudo docker run -it "shmemtest:v2" /bin/bash

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
1182f9eca367        shmemtest:v2        "/bin/bash"         11 seconds ago      Up 11 seconds                           distracted_elion

进入容器,先后执行mmap_shm_wr和mmap_shm_rd,我们得到如下结果:

bash-4.1# mmap_shm_wr
Mmap Share Memory Create and Write Ok
bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

我们接下来尝试一下重启container后是否还能读出数据:

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
1182f9eca367        shmemtest:v2        "/bin/bash"         About a minute ago   Up About a minute                       distracted_elion   
$ sudo docker stop 1182f9eca367
1182f9eca367
$ sudo docker start 1182f9eca367
1182f9eca367
$ sudo docker attach 1182f9eca36
7

bash-4.1# mmap_shm_rd
a b c d e f g h i j k l m n o p q r s t u v w x y z
Mmap Share Memory Read Ok

通过执行结果可以看出,通过mmap映射文件方式,共享内存的数据即便在容器重启后依旧可以得到保留。从原理上看,shm.txt是容器内 的一个文件,该文件存储在容器的可写文件系统layer中,从物理主机上看,其位置在/var/lib/docker/aufs/mnt /container_full_id/下,即便容器重启,该文件也不会被删除,而是作为容器文件系统的一部分:

$ sudo docker inspect -f '{{.Id}}' 1182f9eca367
1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
$ sudo ls /var/lib/docker/aufs/mnt/1182f9eca36756219537f9a1c7cd1b62c6439930cc54bc69e87915c5dc8f7b97
bin  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  sbin    selinux  shm.txt  srv  sys  tmp  usr  var

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats