要检查 Linux 系统内核内存分配状态,应使用 vmstat -m 查看 slab 分配器实时使用情况,而非默认 vmstat;slab 管理 inode、dentry 等小对象,其 objects 持续增长且 pages 偏高可能表明内存泄漏;需结合 /proc/slabinfo、/proc/meminfo 和 slabtop 交叉验证,并区分用户态 cache 与内核 slab 的回收机制。

要检查 Linux 系统内核的内存分配状态,关键不是看常规 vmstat 的默认输出(它主要反映用户态内存和交换行为),而是启用其内核内存管理视角——即通过 vmstat -m 查看 slab 分配器的实时使用情况。slab 是内核用于高效管理小对象(如 inode、dentry、task_struct 等)的内存池机制,它的状态直接体现内核自身内存分配的健康度。
用 vmstat -m 查看内核 slab 内存分配
vmstat -m 会列出当前所有 slab 缓存(cache)的统计信息,包括每种内核对象的分配数量、内存占用、碎片情况等。这是诊断内核内存泄漏、对象堆积或过度缓存的首选入口。
- 在终端直接运行:
vmstat -m,无需 root 权限即可查看大部分信息 - 输出中重点关注列:name(缓存名称,如
ext4_inode_cache、dentry)、objects(当前活跃对象数)、pages(已分配页数)、pagesperslab(每 slab 页数)、size(单个对象字节数) - 若某缓存的 objects 持续增长且不回落,同时 pages 显著偏高,可能暗示对应子系统存在泄漏(例如大量未释放的 dentry 或 socket)
结合其他字段判断内核内存压力
虽然 vmstat 默认输出不直接显示 slab,但某些字段变化可间接反映内核内存紧张:
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
-
free 值极低(如低于几十 MB)且 buff/cache 无法有效回收,说明物理内存已逼近极限,内核可能被迫频繁收缩 slab 缓存(触发
shrink_slab) - si/so 持续非零,尤其 so 较高,表明内存不足已触发交换,而内核为腾出页框可能强制回收 slab 对象
- b(不可中断睡眠进程数)升高 + wa(CPU 等待 I/O 时间)上升,常伴随内核因内存不足而频繁进行 page reclaim 和 writeback,加重 I/O 负担
辅助验证与深入定位
vmstat -m 提供的是快照视图,需结合其他工具交叉确认:
- 用
cat /proc/slabinfo获取更完整、带 per-CPU 统计的原始数据(格式与vmstat -m类似,但字段更全) - 观察
/proc/meminfo中的 SReclaimable(可回收 slab 内存)和 SLAB(总 slab 占用)值,对比vmstat -m总和是否一致 - 若怀疑特定缓存异常,可用
slabtop实时排序监控(如按Active Objs或Use列降序),它基于同一内核接口,但交互更直观
注意常见误区
默认 vmstat(无参数或仅带间隔)不反映内核 slab 状态,它展示的是页回收、交换、缓冲/缓存等高层内存行为。把 free 值低或 cache 高误判为“内核内存问题”是常见错误——实际上 cache 属于可快速回收的用户态页面,而 slab 中的对象由内核直接管理,生命周期更长、回收策略更复杂。

















