嵌入式内核OOM根源分析请求（存储卸载卡场景）

一、核心内核日志 #

Apr  4 07:24:04 captain user.warn kernel: ncd invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0 
...
Apr  4 07:24:05 captain user.err kernel: Killed process 1143 (scd) total-vm:122984kB, anon-rss:47992kB, file-rss:1152kB

二、硬件配置参数 #

DRAM             : 8 GB
DDR clock        : 1200 MHz
Data rate        : 2400 MHz

三、已观测现象 #

• Normal zone空闲内存仅约28MB，系统空闲内存处于极低水平

四、OOM原因初步分析 #

1. 直接触发原因：Normal zone内存耗尽，ncd进程申请内存时无法满足，触发内核OOM-killer机制回收内存。
2. 被终止进程scd（PID 1143）的内存占用细节：
   • 总虚拟内存（total-vm）：122984KB（约120MB）
   • 匿名物理内存（anon-rss）：47992KB（约47MB）—— 进程实际占用的私有物理内存，无法通过文件缓存回收
   • 文件映射内存（file-rss）：1152KB（约1.1MB）—— 与文件关联的内存，可通过回收缓存释放
3. 系统整体内存资源枯竭：OOM触发时不仅Normal zone内存不足，其他内存区域也无足够空间满足分配请求，导致内核不得不终止进程释放内存。

五、内存泄漏排查思路 #

• 长期内存趋势监控：定时采集free、vmstat的输出数据，观察内存占用是否随时间持续增长，且释放后无法回归初始水平。
• 进程级内存跟踪：用top、ps aux --sort=-rss持续监控scd、ncd及其他常驻进程的内存占用变化，定位是否有进程的rss值持续上升。
• 内核内存分析：通过cat /proc/meminfo查看Slab、PageTables等内核内存区域的占用变化；用slabtop分析内核slab缓存的使用情况，排查是否有特定slab对象持续增长导致内核态泄漏。
• 内存分配审计：若条件允许，为目标进程开启内存分配跟踪：用户态进程可用valgrind memcheck工具，内核态可启用kmemleak模块，定位具体的内存泄漏点。

六、日志关键分析要点 #

• 触发与被终止进程区分：ncd是触发OOM的内存申请方，scd是被OOM-killer选中的回收对象，需同时关注两者的内存行为。
• gfp_mask解析：gfp_mask=0x200da对应__GFP_DMA32 | __GFP_HIGHMEM | __GFP_IO | __GFP_FS，说明ncd申请的是DMA32/HIGHMEM区域的内存，结合Normal zone内存耗尽，需排查是否存在内存区域碎片化或特定zone内存分配失衡问题。
• oom_score_adj值：ncd的oom_score_adj=0说明无特殊OOM优先级，内核按默认规则选择终止进程，需确认scd是否因内存占比高被选中。
• 进程内存明细：重点关注anon-rss占比，匿名内存无法通过缓存回收，若该值持续增长，大概率存在用户态内存泄漏；file-rss占比低，说明文件缓存不是内存耗尽的主要原因。

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