大庆市网站建设_网站建设公司_Node.js_seo优化

Linux Slab 使用与泄漏判断完整笔记

适用场景：

• 线上主机 / 容器节点内存占用偏高
• slabtop看到大量kmalloc-* / dentry / inode
• 需要判断是否 slab 泄漏，还是正常缓存行为

一、Slab 基础认知（先统一共识）

1. 什么是 Slab

• Slab 是 Linux 内核用于小对象内存分配的机制

• 常用于：

  • inode / dentry
  • socket / skbuff
  • kmalloc
  • 文件系统 / 网络 / 内核子系统

2. 一个核心原则

Slab 的设计目标就是“尽量缓存、尽量用满”

因此：

• Slab 大 ≠ 问题
• Active 接近 100% ≠ 泄漏

二、slabtop 输出如何正确解读

常用命令

slabtop -o -s c|head-20

关键字段说明

三、最容易误判的点（重点）

1️⃣ Active / Total Objects ≈ 100% 正常吗？

✅大多数情况下是正常的

原因：

• 内核 cache 会尽量保持对象被复用
• 业务活跃时 Active 本就会很高

❌泄漏的核心不是“用得多”，而是：

用完之后不释放，且数量持续增长

四、判断 Slab 是否异常的正确方法（标准流程）

Step 1：锁定“嫌疑 slab”

重点关注：

• kmalloc-*
• buffer_head
• skbuff_head_cache
• TCP

记录 cache 名称，例如：

kmalloc-1k kmalloc-512

Step 2：多次采样，看趋势（最重要）

方法一：slabtop 连续观察

watch-n5slabtop -o -s c

判断标准：

方法二：对比 /proc/slabinfo（更严谨）

grepkmalloc-1k /proc/slabinfosleep60grepkmalloc-1k /proc/slabinfo

关注字段：

• active_objs
• num_objs
• slabs

Step 3：结合内存回收能力一起判断

cat/proc/meminfo|egrep'Slab|SReclaimable|SUnreclaim'

判断逻辑

Slab 泄漏几乎一定体现在 SUnreclaim 上

五、不同 Slab 的“风险等级速查表”

🔴 高风险（需要重点关注）

🟢 低风险（通常为正常缓存）

dentry / inode 再大，也极少是泄漏

六、典型业务场景与 Slab 特征

1️⃣ 文件系统 / 日志 / 数据库

• dentry
• inode_cache
• radix_tree_node

2️⃣ 容器 / K8s 节点

• proc_inode_cache
• ovl_inode
• dentry

3️⃣ 网络 / 高并发服务

• TCP
• skbuff
• kmalloc-*

七、进阶：确认是否真实泄漏（慎用）

kmemleak

echoscan>/sys/kernel/debug/kmemleakcat/sys/kernel/debug/kmemleak

slab trace（生产慎用）

echo1>/sys/kernel/slab/kmalloc-1k/trace

八、可以直接写进报告的总结模板

slab 是否异常不能依据单次 slabtop 输出判断，而应通过多次采样观察同一 cache 的对象数与 cache size 是否持续单向增长。若在业务负载稳定前提下，kmalloc-*等 slab 的num_objs / slabs持续增长，且SUnreclaim同步上升，则可初步判断存在 slab 泄漏风险。

九、一句话工程师心法

看 slab：先看类型，再看趋势，最后看 SUnreclaim。