每个容器的 Memory Cgroup 路径根据其 和唯一标识符来确定■★◆■。路径的基本格式如下：

　　mmap不仅可以为程序分配匿名页， 它还是一种内存映射文件的方法，允许将文件或设备的内容映射到进程的地址空间中。通过 mmap，可以直接访问甚至修改文件内容，就像访问内存一样，这通常比传统的文件 I/O 操作更高效★◆■。例如以下程序■◆：

　　可以发现，linux进程地址空间是由一个个vm_area_struct(vma)组成，每个vma都有自己地址区间。如果你的代码panic或者Segmentation Fault崩溃■■■，最直接的原因就是你引用的指针值不在进程的任意一个vma区间内。你可以通过 /proc/ /maps 来观察进程的vma分布。

　　在执行这个程序前，做一次drop cache操作■★，用来清理系统已有的pagecache：

　　当这么做的时候，会发现挂载点(下图的/data)对应的文件系统是tmpfs，这意味着/data里的数据实际上都存储在内存中。

　　缺页中断进入更复杂的流程，page申请变慢, 直接阻塞用户进程，造成应用程序性能下降。

　　如果没有为emptyDir卷设置sizeLimit◆★■，/data目录下的文件将占用Pod的内存；如果Pod没有设置内存limit，则/data可能消耗掉Node上全部的内存★■◆。

　　malloc函数增大了进程虚拟地址空间的heap容量★■■◆◆◆，扩大了mm描述符中vma的start和end长度，或者插入了新的vma；但是它刚完成调用后★◆★◆■★，并没有增大进程的实际内存使用量。

　　下面我们再测试一个小程序，创建一个文件并写入100MiB数据，然后连续两次读文件，观察/proc/meminfo前后变化◆★★。

　　基于4■★★.1的启发，只要多个进程mmap相同一个文件◆◆■，就可以通过这个文件实现共享内存，完成多进程通信■■★★，这种方式叫做共享文件映射。

　　进一步说，malloc申请到的地址■★◆■★■，在得到真实的使用之前◆◆◆◆■★，必须经历缺页中断，完成建立虚拟地址到物理地址的映射。完成物理页分配的虚拟地址空间才会被计算到内存使用量中■■◆★。

　　导语 Linux下开发者习惯在物理机或者虚拟机环境下使用top和free等命令查看机器和进程的内存使用量，近年来越来越多的应用服务完成了微服务容器化改造，过去查看、监控和定位内存使用量的方法似乎时常不太奏效。如果你的应用程序刚刚迁移到K8s中，经常被诸如以下问题所困扰★★★★：容器的内存使用率为啥总是接近99%？malloc/free配对没问题，内存使用量却一直上涨？内存使用量超过了限制量却没有被OOM Kill? 登录容器执行top,free看到的输出和平台监控视图完全对不上？★◆◆★... 本文假设读者熟悉Linux环境◆◆◆，拥有常见后端开发语言(C/C++ /Go/Java等)使用经验◆◆◆，希望后面的内容能在读者面临此类疑惑时提供一些有效思路。

　　调用 mmap 进行文件映射的时候，内核首先会在进程的虚拟内存空间中创建一个新的虚拟内存区域 VMA 用于映射文件◆◆★■，通过 vm_area_struct-vm_file 将映射文件的 struct flle 结构与虚拟内存映射关联起来。

　　‍发现进程的rss依然约101MiB。因此和前面提到的共享内存一样，mmap文件映射部分的大小属于进程的rss而不属于容器的rss。

　　pagecache用于提升磁盘文件读写性能，pagecache被回收意味着程序IO性能下降，延迟增加。因此生产环境一般严禁dropcache操作。

　　可以发现接近pagecache占了接近100MiB，而rss使用量非常少。必须认识到■★■◆■★，pagecache也属于容器内存使用量。

　　将2■★★■★.2中的程序稍作修改令其常驻不退出，然后制作成容器镜像★■■■◆，部署在TKEx平台中，观察内容监控数据如下。

　　以下是一个C语言小程序来演示如何通过读写文件来产生PageCache◆◆◆■★■, 这个程序写100MiB数据到指定的文本文件中。

　　K8s容器环境下，容器里的进程都归属同一个cgroup控制组，本文只关注内存控制组(memcg)。把刚才的代码做成容器镜像，部署在TKEx环境里★★, 观察容器内存使用相关指标★◆■■。

　　‍跟踪MEMCG_RSS的记录情况，发现只有匿名页的数量被，这和前面观察的进程的RSS不一样■■。共享内存page只被计入MEMCG_CACHE，即便它位于匿名LRU。

　　类别进程的 RSS容器的 RSSbrk 分配mmap 匿名映射共享内存mmap 文件映射栈 (stack)二进制文件动态链接库页表

　　编写如下程序然后制作容器镜像★◆，部署到TKEx平台■◆■◆★◆，将容器内存限制设置为1GiB■■◆■◆。

　　那memory cgroup的RSS的计算方法是不是就是简单地把memcg下归属的所有的进程RSS简单求和呢？显然不是■★◆。通过追溯★★, 发现这个数值来来自容器所属cgroup path下的memory.stat文本中的rss字段。

　　进程的RSS(Resident Set Size)是当前使用的实际物理内存大小，包括代码段、堆■◆◆◆、栈和共享库等所使用的内存■■◆, 实际上就是页表中物理页部分的全部大小。

　　事实上，第一次读写文件产生的pagecache，都是Inactive的◆★◆◆◆★，只有当它再次被读写后，才会被对应的page放在Active LRU链表里。Linux使用了2个LRU链表来分别管理Active 和Inactive pagecache，当系统内存不足时■◆★★，处于Inactive LRU上的pagecache会优先被回收释放，有很多情况下文件内容往往只被读一次，比如日志文件，它们占用的pagecache需要首先被回收掉。

　　这些指标究竟是什么含义？在不同的应用场景下需要重点关注哪些指标？让我们从回顾linux进程地址空间开始，逐步挖掘容器内存使用奥秘。

　　频繁进行文件读写的容器经常会遇到内存使用率一直接近99%的情况■■■，就是由于linux为了提升文件读写性能，在memcg的限制内，尽可能地分配更多的pagecache。

　　相对于共享文件映射，共享匿名映射也能实现共享内存，但只适用于父子进程之间。实现原理相对于共享文件映射略有类似，同样依赖了pagecache，但这里的文件不再是具体的磁盘文件，而是tmpfs。tmpfs是一个基于内存实现的文件系统，因此基于tmpfs的共享内存不会产生真实的磁盘IO。后面会了解到，基于ipc的共享内存★■■★◆★，即1.1里通过shmget和shmat实现的共享内存，也是依靠tmpfs完成的★★■■★■。

　　‍先初始化一个100MiB的文本文件，内容全部是字母A■◆★★★■; 然后通过mmap将文件映射到程序地址空间里，通过memset将文件内容全改成字母B◆★■。借助mmap文件映射◆◆◆★★，使用内存操作就能完成文件读写■■。相较于标准buffered io, mmap文件映射会拥有更好的性能，因为它避开了用户空间和内核空间的相互拷贝★◆★◆，这个优势在一次读写几十上百MiB的场景下尤为突出。

　　找到memcg path后◆◆■，可以发现目录下有很多记录文件★■★★◆，这里关注memory◆■.stat:

　　Page cache 是操作系统内核用来缓存文件系统数据的一种机制。它通过将文件数据缓存到内存中，从而减少磁盘 I/O 操作■■★◆，提高文件读取的性能◆■。当应用程序读取文件时，内核会首先检查 page cache，如果数据已经在缓存中■◆■◆◆，则直接从内存中读取，避免了磁盘访问。

　　开发者可能很少感知自身程序pagecache的使用情况，容器平台会对程序的内存使用做限制，那么是否需要担心pagecache的上涨导致程序内存使用量超过容器内存限制，导致程序被OOM Kill?

　　公司内部存在大量的IPC共享内存的使用场景■◆，比如spp服务端框架。例如以下C语言程序例子：

　　‍在缺页中断处理过程中，如果vma非匿名（即文件映射）◆◆，linux首先通过 vm_area_struct-vm_pgoff激活对应的pagecache并预读部分磁盘文件内容到pagecache中，然后在页表中创建PTE并与pagecache文件页关联◆◆，完成缺页中断■■★，此后对vma的访问实质上都是对pagecache的访问。进程1和进程2的共享文件映射，实质上是各自vma里的file字段最终指向了相同的文件■★◆◆，即相同的inode。进程1和进程2对各自vma的访问也实质上是对相同的pagecache进行访问，这就是基于文件映射实现共享内存的原理。当然■■◆★，对vma的内容修改也会导致对pagecache的修改，最终通过脏页回写完成对磁盘文件的修改，因此这种共享内存的方式会产生线 共享匿名映射

　　进程RSS组成 描述 匿名页 通常来源于 malloc，进入 brk 或者 mmap 匿名映射 共享内存 来自 shmget 系列调用 mmap 文件映射 通过 mmap 调用映射文件到进程地址空间 栈 (stack) 进程的调用栈 二进制文件 加载进程本身的二进制文件占用的内存 动态链接库 加载的动态链接库（共享库）占用的内存 页表 内核中存储页表的部分 2.2 容器(memcg)的RSS

　　发现rss确实增长了150MiB，pagecache少了45MiB，总内存达到1023MiB, 并没有超过1GiB的限制。原因是在memset进入缺页中断分配物理页时，系统发现内存使用量会超过memcg limit的情况下，会先尝试回收pagecache以满足分配需求， 优先回收前面提到的Inactive File。由此可知，进程的rss不超过memcg limit的前提下, 可以放心申请使用内存★◆◆■，系统会及时释放pagecache来满足需求。pagecache属于内核■★★，不属于用户，当用户需要内存时，内核会通过回收pagecache来归还内存◆★★■，但这可能是有代价的。

　　1.1中通过观察/proc/$pid/status和top的输出，我们得出了进程的RSS估算方法，即★◆◆◆: 1）占主要部分的 malloc导致的匿名页(brk/mmap匿名映射) + 使用shmem共享内存 + mmap文件映射；2）stack部分，text部分和动态链接库部分，页表部分，通常占比很小★◆■。

　　容器中的cache占用统计既包含了读写文件产生的pagecache，也包括了使用共享内存的大小。

　　容器环境下, 内存使用量接近memcg限制时候，继续尝试申请分配内存会先触发pagecache回收，以满足分配需求。