Linux内存泄漏怎么排查_free与vmstat解析【教学】

8次阅读

Linux 内存泄漏排查需先用 free 和 vmstat 观察 available 持续下降与 buff/cache 单向上涨、sr/si/so 异常等表层信号，再结合 ps、/proc/meminfo、slabtop、perf 等工具定位进程或内核泄漏源。

Linux 内存泄漏怎么排查_free 与 vmstat 解析【教学】

Linux 内存泄漏排查核心在于识别“持续增长且不释放”的内存占用，free 和 vmstat 是两个轻量、实时、无需安装的诊断入口工具，但它们只反映表层状态，需结合逻辑判断和进一步追踪才能定位真实泄漏点。

free 命令：看内存总量与缓存 / 可用性变化趋势

free -h（或 free -m）输出中重点关注三列：

available：内核估算的当前可立即分配给新进程的内存（含可回收的 page cache、slab 等），比 free 列更真实反映系统余量；
buff/cache：包含页缓存（page cache）、目录项 / 索引节点缓存（dentries/inodes）、slab 分配器对象（如 kmalloc 缓存）等，正常会随 I/O 波动，但若长期单向上涨且 available 持续下降，需警惕 slab 或内核模块泄漏；
used 不等于“真实应用占用”——它 = total − free − buff/cache，而 buff/cache 中大量内容可被快速回收，所以不能单看 used 增长就断定泄漏。

建议每 5–10 秒运行一次观察：watch -n 5 'free -h'。若 available 持续走低、buff/cache 却未同步回落，说明有内存被“钉住”无法回收，可能是内核驱动、BPF 程序、或未正确释放的内核内存（如 kmalloc/kmem_cache_alloc 后未 kfree）。

vmstat：抓取内存压力与换页行为信号

vmstat 1 每秒输出一行，重点看以下字段：

si/so（swap in/out）：非零且持续出现，说明物理内存严重不足，已开始换页——这是内存紧张的强信号，但不直接等于泄漏（可能是配置过小或突发负载）；
bi/bo（block in/out）高 + cache 高 → 可能是缓存堆积，未必泄漏；
in（interrupts）和 cs（context switches）异常升高，配合内存下降，可能指向高频内核分配路径（如网络收包、定时器回调反复 malloc）；
sr（scan rate，旧版 vmstat 显示为 re）> 0 且持续存在 → 内核 kswapd 正在积极回收内存，说明 LRU 链表压力大，常伴随 available 走低。

注意：vmstat 本身不显示谁占了内存，但它能告诉你“系统是否在挣扎”。如果 free 显示 available 快见底，而 vmstat 的 sr 居高不下、si/so 开始跳动，基本可确认存在未释放资源，下一步必须深入进程或内核层面。

定位泄漏源的实用组合动作

仅靠 free/vmstat 无法定位到具体进程或代码行，但可快速缩小范围：

用 ps aux --sort=-%mem | head -10 查内存 RSS 最高的用户进程，检查其生命周期是否异常（如本该退出却常驻、连接数线性增长）；
用 cat /proc/meminfo | grep -E "SReclaimable|Slab|KernelStack|PageTables" 关注内核内存子系统：若 Slab 持续上涨且 SReclaimable 不增，大概率是 slab 分配器中某 kmem_cache 未释放对象（常见于驱动或内核模块）；
对可疑进程，用 pmap -x <pid></pid> 看其地址空间分布，关注 anon 区域是否随时间不断扩张；
内核态怀疑时，启用 slabtop 实时观察各缓存使用量，或通过 /sys/kernel/slab/ 下各 cache 目录的 objects、slabs 文件跟踪增长；
终极验证：用 perf record -e kmem:kmalloc,kmem:kfree -a sleep 30 录制内核内存事件，再用 perf script 分析分配 / 释放是否匹配（需开启 CONFIG_KPROBE_EVENTS 和 debugfs）。