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

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

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

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

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

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

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

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

　　《九王》EA评测★■◆：一天玩了8个小时★■■◆★，但不是因为我有品位/

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

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

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

　　《编码物候》展览开幕 北京时代美术馆以科学艺术解读数字与生物交织的宇宙节律

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

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

　　主站 商城 论坛 自运营 登录 注册 《九王》EA评测：一天玩了8个小时◆■，但不是因为我有品...

　　金亨泰公开《剑星》PC 版所需笔记本电脑配置★◆★◆◆：最低 RTX 3050 Ti

　　传苹果正在为 iPhone、iPad 和 Apple Watch 开发触觉按钮

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

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

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

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

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

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

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

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

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

　　《明末：渊虚之羽》成都试玩报告：常玩常新/

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

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

　　国务院任免21名干部★■★！刚卸任副省长的她进京履新，他“空降”江苏后被免去公安部职务

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

　　海思宣布华为 WATCH 5 近期首发上市，支持尊界 S800 星闪车钥匙

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

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

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

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

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

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

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

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

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

　　主站 商城 论坛 自运营 登录 注册 《明末■■◆★■：渊虚之羽》成都试玩报告◆★■■：常玩常新 Marvin 2025-...

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

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

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

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

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