sar命令不支持直接查看历史slab内存占用，因其未被sadc采集且不在sysstat日志中；可间接通过sar -r/-B分析内存压力信号，或主动定时记录/proc/slabinfo实现历史追溯。
sar 命令本身不支持直接查看历史 slab 内存占用。这是关键前提——slab（内核对象缓存，如 dentry、inode、buffer_head 等）的统计信息未被 sysstat 默认采集，也不包含在 /var/log/sa/saDD 二进制日志中，无论你是否启用 ENABLE_PROCESS_STATS 或升级到最新版 sysstat。
原因很明确：
-
sar的历史数据来源是sadf解析/var/log/sa/下由sa1（即sadc）采集的二进制快照； -
sadc默认采集项由SADC_OPTIONS控制，其支持的内核指标集中在 CPU、内存总量、swap、IO、网络等宏观层面； - *slab 统计（如
/proc/slabinfo或 `cat /sys/kernel/slab//stats）从未被sadc原生支持**，sysstat 官方文档和源码中均无-l、--slab` 或类似选项。
那怎么查历史 slab 占用？
你无法用 sar -f 回溯 slab，但有两个可行替代路径：
✅ 方案一：用 sar 查 间接相关 内存压力信号（适用于事后分析）
虽然看不到 slab 具体分配，但可观察 slab 泛滥常引发的系统表现：
-
高 page reclaims / low available memory
sar -r -f /var/log/sa/sa$(date -d '3 days ago' +%d) | grep -E "^(0[0-9]|1[0-9]|2[0-3])"
关注
kbmemfree、kbbuffers、kbcached、kbcommit和available（若 sysstat ≥12.2）。若available持续低于总内存 10%，且kbswpused上升，说明内存紧张——slab 可能是诱因之一。 -
异常高的 kswapd 或 direct reclaim 活动（需结合 vmstat 历史）
sar不记录pgpgin/pgpgout细粒度页回收，但可用：sar -B -f /var/log/sa/sa$(date +%d) # 查 pgin/s, pgpgout/s, pgmajfault/s
若
pgmajfault/s显著升高，可能反映 slab 回收失败后触发大量磁盘换页。
✅ 方案二：主动补采 slab 数据（推荐，需提前部署）
若你希望未来能查 slab 历史，必须自行补充采集机制：
-
每 10 分钟记录一次
/proc/slabinfo快照（与 sysstat 同步节奏）：
编辑 root 的 crontab：*/10 * * * * /bin/bash -c 'echo "$(date +%Y-%m-%d %H:%M): $(cat /proc/slabinfo 2>/dev/null | tail -n +3 | awk '''{sum+=$3*$4} END{print sum}''')" >> /var/log/slab-history.log'这会追加时间戳 + 当前 slab 总内存占用（KB）。
-
或使用
ss+awk提取重点 cache（如 dentry、ext4_inode_cache）：*/10 * * * * /bin/bash -c 'echo "$(date +%F %T) $(awk "/^dentry/ {print \$3*\$} /^ext4_inode_cache/ {print \$3*\$}" /proc/slabinfo 2>/dev/null | paste -sd " " -)" >> /var/log/slab-dentry-inode.log' 配合
logrotate归档，后续用awk/gnuplot分析趋势。
⚠️ 注意：
/proc/slabinfo输出格式版本差异大（如 5.10+ 新增Active_objs字段），脚本需按内核版本微调字段索引。
❌ 常见误区提醒
-
sar -v显示的是 inode、file-nr、pty 等内核表用量，不是 slab； -
sar -r中的kbcached是 page cache，和 slab cache 完全不同； -
sar -A或sadf -- -v也不会出现 slab 相关列； - 第三方工具如
ksar、grafana + prometheus也无法从sa文件里“挖出”不存在的数据。
不复杂但容易忽略：slab 历史不可回溯，是 sar 的设计边界。真要长期监控，得自己搭一层轻量采集。
