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 平稳波动属正常,持续单向增长才需要继续追。