关于/proc/meminfo各项内存值无法相加匹配MemTotal的问题咨询

嘿，我完全懂你现在的困惑——对着/proc/meminfo里的数值加加减减，结果却和MemTotal对不上，这种感觉真的让人挠头！核心原因其实很简单：这些字段并不是完全互斥的独立分类，很多项之间存在包含关系，直接粗暴做减法肯定会算错。

给你拆解几个关键的重叠点：

• Active和Inactive是按内存活跃状态划分的，它们本身就包含了其他字段的内容：你看你的数据里Active(anon) + Active(file)刚好等于Active，Inactive(anon) + Inactive(file)等于Inactive——这说明Active/Inactive已经把匿名页（AnonPages）、文件缓存（Cached）的对应部分包含进去了，你再单独把这些字段拿出来减，相当于重复扣除了内存。
• Slab、KReclaimable和SReclaimable是重复统计：KReclaimable其实就是SReclaimable，它是Slab内存池里可回收的部分，所以Slab = SReclaimable + SUnreclaim，你把这三个都放进减法公式里，等于把可回收的Slab内存扣了两次。
• Shmem也属于重叠项：它包含了匿名共享内存、tmpfs这类内存，已经被算在AnonPages或者Inactive(anon)里了，重复计算会进一步拉低结果。
• 另外DirectMap*系列是内核记录物理内存到虚拟地址的映射关系，这部分和前面的内存统计是重叠的，不是额外的内存占用，不能单独加进去。

回到你的OOM问题，从你的/proc/meminfo数据来看，Active(anon)高达308GB，这是内存疯涨的核心——大部分内存被进程的匿名内存占用了（比如内存泄漏的进程、大内存业务进程），Shmem的30GB也可能是共享内存或tmpfs的消耗。你可以用这些工具定位问题：

• 用top或者ps aux --sort=-%mem找出内存占比最高的进程；
• 用smem工具来统计内存，它会自动处理共享内存的重复统计问题，给出更准确的进程内存占用情况；
• 也可以用vmstat或者sar查看内存的变化趋势，确认是突然暴涨还是缓慢泄漏。

备注：内容来源于stack exchange，提问作者lordofire