Linux服务器内存被‘吃’光了？手把手教你用/proc/meminfo和slabinfo定位内核内存泄露

Linux服务器内存被‘吃’光了？手把手教你用/proc/meminfo和slabinfo定位内核内存泄露

凌晨三点，服务器告警铃声突然响起。监控系统显示，某台核心业务服务器的可用内存正以每小时2%的速度持续下降，距离触发OOM Killer只剩不到6小时。作为值班运维，你必须在早高峰前解决这个"内存黑洞"。本文将带你像侦探破案一样，通过/proc/meminfo和/proc/slabinfo这两个"现场勘查工具"，快速锁定内核内存泄露的元凶。

1. 紧急诊断：用户态还是内核态泄露？

当服务器出现内存缓慢耗尽时，首先要确定泄露发生在用户态还是内核态。这就像医生区分内科还是外科问题——治疗方法完全不同。

1.1 查看内存全景图：/proc/meminfo

登录问题服务器，运行以下命令获取内存快照：

cat /proc/meminfo | grep -E 'MemTotal|MemFree|Slab|SReclaimable|SUnreclaim'

典型的内核泄露场景会显示如下特征：

MemTotal: 32817152 kB MemFree: 1024000 kB # 持续减少 Slab: 8388608 kB # 异常偏高 SReclaimable: 524288 kB SUnreclaim: 7864320 kB # 不可回收内存占比极高

关键指标解读：

注意：建议同时保存free -m输出作为辅助参考，但/proc/meminfo的Slab数据更精确

1.2 时间轴对比分析

内存问题诊断必须引入时间维度。建议按以下步骤操作：

1. 创建监控时间点：

   watch -n 300 "date +'%F %T' >> mem.log; \ cat /proc/meminfo | grep -E 'MemFree|Slab|SUnreclaim' >> mem.log"

2. 两小时后停止监控，分析变化趋势：

   awk '/Slab/{print $2}' mem.log | graph -w 100 -h 10

如果Slab值呈线性增长，而MemFree同步减少，基本可判定是内核态泄露。

2. 锁定嫌犯：Slab缓存分析

确认内核泄露后，下一步是找出具体哪个Slab缓存类型在"偷"内存。

2.1 获取Slab详细清单

cat /proc/slabinfo | awk 'NR==1; $3>1024 {print}' | sort -k2 -nr

这个命令会：

1. 保留表头信息
2. 过滤对象大小>1KB的缓存（小对象泄露影响有限）
3. 按活跃对象数降序排列

重点观察列：

• <active_objs>：正在使用的对象数量
• <objsize>：单个对象大小（字节）
• <objperslab>：每个Slab页能存放的对象数

2.2 动态监控增长趋势

对可疑的Slab类型进行持续监控：

watch -n 60 "date +'%T'; \ awk '/kmalloc-8192/{print \$2,\$3}' /proc/slabinfo"

如果发现某个缓存的active_objs持续增加而num_objs不变，就是典型的内存泄露特征。

常见泄露大户：

• kmalloc-*：通用内存缓存
• dentry：目录项缓存
• buffer_head：文件系统缓存
• skbuff_head_cache：网络数据包缓存

3. 深度取证：Slab调试技巧

对于确认泄露的Slab缓存，需要进一步取证分析。

3.1 启用Slab跟踪（无需编译内核）

# 设置跟踪标记 echo 1 > /sys/kernel/slab/<leaking_slab>/trace # 查看分配调用栈 cat /sys/kernel/slab/<leaking_slab>/alloc_calls # 查看释放调用栈 cat /sys/kernel/slab/<leaking_slab>/free_calls

3.2 解读调用栈信息

假设我们发现kmalloc-8192的分配调用栈显示：

__alloc_skb+0x98/0x238 age=430/366961/410069 pid=0-1467 cpus=1,3 pskb_expand_head+0xa0/0x2b0 age=22161/203241/396156 pid=0-1467 cpus=1

这表示：

1. 内存主要被网络栈的__alloc_skb函数申请
2. 申请频率较高（age值跨度大）
3. 涉及多CPU核心（cpus=1,3）

提示：如果free_calls中对应函数调用次数明显少于alloc_calls，就是典型的泄露证据

4. 应急处理与根治方案

4.1 临时缓解措施

如果暂时无法重启服务，可以尝试：

1. 手动回收Slab缓存：

   echo 2 > /proc/sys/vm/drop_caches

2. 限制特定Slab增长：

   echo "limit <slab_name> 1000" > /proc/slabinfo

4.2 长期解决方案

根据调用栈分析结果，通常需要：

1. 修复内核模块的内存释放逻辑
2. 更新有问题的驱动版本
3. 对第三方内核模块进行压力测试

典型修复案例：

• 网络驱动未正确释放DMA缓冲区
• 文件系统模块的inode缓存引用计数错误
• 自定义内核模块的kmalloc/kfree不匹配

5. 高级调试技巧

对于复杂场景，可能需要更深入的调试手段：

5.1 使用SystemTap监控

stap -e 'probe kernel.function("kmem_cache_alloc").return { if (execname() == "your_process") { printf("%s %d\n", probefunc(), $bytes) } }'

5.2 内存泄露模式分析

不同类型泄露的特征对比：

5.3 自动化监控脚本

建议部署以下脚本到核心服务器：

#!/bin/bash SLAB_LIMIT=$(( $(grep MemTotal /proc/meminfo | awk '{print $2}') * 20 / 100 )) while true; do CURRENT_SLAB=$(grep Slab /proc/meminfo | awk '{print $2}') [ $CURRENT_SLAB -gt $SLAB_LIMIT ] && \ alert "Slab usage exceeded 20% of total memory" sleep 300 done

记得去年处理过一台数据库服务器，dentry缓存泄露导致每天凌晨准时OOM。最终发现是某个监控工具频繁扫描/proc目录却不关闭文件描述符。这种案例教会我：内存问题往往隐藏在看似无关的角落。