首页/系统/Linux 运维命令速查/slabtop 内核 Slab 占用排行
性能与监控48 条

slabtop 内核 Slab 占用排行

内存被内核对象吃掉(Slab 高)时用 slabtop 排序看具体缓存:dentry、inode_cache 等增长能解释「没进程吃内存」的怪象。

Linux 运维命令速查系统更新于 2026-10-13

slabtop 是什么

slabtop 按缓存对象展示内核 Slab 内存的占用排行。排查内存时常见的怪象是「没有进程占内存,可用内存却一直下降」,答案往往在 Slab 里:dentry、inode_cache 这类对象会随文件访问规模增长。slabtop 把每一类对象的大小和数量排出来,让这部分内存变得可见。

基本信息

所属procps-ng
语法slabtop [-s 排序键] [-o] [-d 秒]
权限要求读取 /proc/slabinfo 通常需要 root
相关指标/proc/meminfo 中的 Slab、SReclaimable、SUnreclaim

典型使用场景

  • 可用内存持续下降但找不到吃内存的进程
  • 海量小文件场景确认 dentry 与 inode 缓存规模
  • 评估是否需要调整 vfs_cache_pressure 策略
  • 容器宿主机上排查文件缓存对内存的挤压
  • 内核升级或业务变更前后对比对象数量变化
  • 排查不可回收内存持续增长引发的 OOM 风险

常用示例

常用示例
slabtop                                 # 交互式查看,默认按对象数排序
slabtop -s c -o | head -n 20            # 按缓存大小排序,一次性输出
grep -E 'Slab|SReclaimable|SUnreclaim' /proc/meminfo   # 看三档总量
cat /proc/slabinfo | head -5            # 直接读原始数据
slabtop -d 5                            # 每 5 秒刷新(交互模式)
free -m                                 # 结合整体内存视图一起判断

meminfo 相关项

项含义关注点
Slab内核对象占用总量等于可回收与不可回收之和
SReclaimable可回收 Slab内存紧张时系统会自动回收
SUnreclaim不可回收 Slab持续增长需警惕
dentry目录项缓存海量文件访问后常见增长
inode_cache索引节点缓存与同时访问的文件数相关
Slab 分可回收与不可回收两部分:SReclaimable 在内存压力下会自动归还,不必急于人工干预;真正需要留意的是 SUnreclaim 的持续增长。
slabtop 需要读取 /proc/slabinfo,普通用户通常没有权限,输出的对象数量也会被限制;排查必须用 root,否则看到的是不完整视图。
dentry 与 inode 缓存偏高多与大量文件访问有关,属于可回收部分;如果希望系统更积极地回收,可以评估调整 vfs_cache_pressure,但要结合业务 IO 特征,不建议盲目调低。
判断 Slab 是否异常,看趋势比看单点更有效:间隔一段时间采集 /proc/meminfo 里的三档数值,SUnreclaim 平稳波动属正常,持续单向增长才需要继续追。

易错点

  • 把可回收 Slab 当成内存泄漏:它是正常的缓存占用,内存紧张时系统会自动回收
  • 不用 root 运行 slabtop:对象数被截断,看到的不是完整数据
  • 只看 Slab 总量不看构成:分不清可回收与不可回收,结论容易跑偏
  • 据此直接调内核参数:不了解业务 IO 特征就改 vfs_cache_pressure,可能拖慢文件访问

数据来源与参考

  • man 1 slabtop(procps-ng)
  • man 5 proc(/proc/slabinfo)

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌