排查EC2实例CW mem_used_percent异常致OOM及内存统计不符问题

CloudWatch（以下简称CW）的mem_used_percent指标由CW Agent从/proc/meminfo读取字段计算，默认逻辑是：
mem_used_percent = (MemTotal - MemFree - Buffers - Cached - SReclaimable) / MemTotal * 100
即所有不可被系统直接回收的物理内存都计入used，包含用户态进程占用、内核态占用、预留内存等所有类别。
使用top按%MEM排序看到的进程内存占比总和只有20%，核心原因是top默认的%MEM列仅统计进程的常驻匿名页（RSS），至少漏算4大类内存占用，自然和CW数值对不上。

按以下步骤计算，最终统计值和CW指标的误差不会超过1%（仅来自采集时间差）：

1. 先在EC2实例内执行cat /proc/meminfo获取核心内存字段（单位统一为kB），先算出CW口径的已用内存基准值：

   基准已用内存 = MemTotal - (MemFree + Buffers + Cached + SReclaimable)
   用这个值除以MemTotal转成百分比，先和CW展示的mem_used_percent做校验，确认口径一致。

2. 逐类核对未被top统计的内存项，加总后和基准值对齐即可定位泄漏点：
   • 内核Slab不可回收内存（SUnreclaim）
     这是无进程归属内存泄漏的最常见原因，top完全不统计这部分。ext4/xfs元数据缓存、overlay文件系统dentry缓存、nf_conntrack连接表、内核模块/驱动分配的未释放内存都会进入这部分。
     排查命令：
     • 直接读取/proc/meminfo中的SUnreclaim字段值，换算成占总内存的比例
     • 如果这部分占比高，执行slabtop -s c按占用排序，看排名靠前的slab项：常见异常项包括dentry、inode_cache、xfs_inode、nf_conntrack，对应不同的泄漏场景。
   • 共享内存类占用
     top默认不会全量统计多进程共享的内存页，这部分包括：tmpfs/ramfs挂载点存储的文件（比如/dev/shm下的临时文件、容器tmpfs类型的emptyDir挂载）、SysV共享内存段、进程mmap的共享映射页。
     排查命令：
     • 执行df -h | grep -E 'tmpfs|ramfs'看各内存文件系统的已用大小
     • 执行ipcs -m查看SysV共享内存的分配占用
   • 系统预留内存
     这类内存也不会计入进程RSS：
     • 大页内存：/proc/meminfo中HugePages_Total * Hugepagesize为总大页预留内存，一旦预留就不会被普通进程/缓存使用，直接计入CW的used统计
     • 设备驱动预留内存：ENA网卡驱动、EBS存储驱动、GPU驱动等预留的DMA内存，可通过/proc/meminfo的VmallocUsed字段看总大小，执行cat /proc/vmallocinfo | sort -k2 -n -r看具体分配项
   • 进程内存统计遗漏
     top统计RSS时会把多进程共享的内存页只算一次，大量进程依赖同一个共享库的时候会有少量统计偏差；另外如果是在宿主机上跑容器，未进入top默认进程命名空间的容器进程内存也会被漏算，可进入对应cgroup目录查看memory.stat确认。
3. 把上述所有项的大小加总，再加上内核栈、页表等零碎内核占用（一般占总内存的1%-3%），和第一步算出的基准已用内存基本完全一致。

• 如果执行sync && echo 2 > /proc/sys/vm/drop_caches后，CW的mem_used_percent直接回落至20%左右，说明是dentry/inode缓存泄漏，常见于旧版本overlay2驱动、应用大量创建删除小文件但未释放文件句柄的场景，长期可通过升级内核版本、调大vm.vfs_cache_pressure参数加快缓存回收、修复应用句柄泄漏解决。
• 如果tmpfs挂载点占用持续上涨，检查对应挂载点下是否有进程持续写入临时文件未清理。
• 如果nf_conntrack对应的slab项占比过高，检查实例是否存在大量未释放的短连接，调整conntrack表上限或开启连接回收。
• 如果是驱动预留内存持续上涨，优先升级EC2使用的内核、ENA网卡驱动、EBS驱动，AWS官方维护的旧版AMI存在过已知的驱动内存泄漏bug。

内容的提问来源于stack exchange，提问作者plffy