关键在于建立持续、低干扰、高精度的RSS时间序列采集机制,推荐读取/proc/[pid]/status的VmRSS字段,用脚本每5–30秒采样并记录时间戳、RSS和进程名,再结合趋势分析与smaps验证内存泄漏。

分析应用程序运行时的内存增长趋势,关键不是看单次快照,而是建立持续、低干扰、高精度的时间序列采集机制。重点盯 RSS(Resident Set Size),它反映进程实际占用的物理内存,比 VSS 或 %MEM 更具诊断价值。
用 /proc/[pid]/status 精准采集 RSS
推荐直接读取 /proc/[pid]/status 文件中的 VmRSS 字段,避免使用 ps 或 top——它们字段易变、精度低、还可能引入额外开销。
- 执行命令:
grep VmRSS /proc/1234/status(1234 替换为实际 PID),输出类似VmRSS: 184520 kB - 脚本中建议用 awk 提取:
awk '/^VmRSS:/ {print $2}' /proc/1234/status - 同时提取进程名(comm):
awk '/^Name:/ {print $2}' /proc/1234/status | tr -d '\0' - 采样频率设为 5–30 秒:太密会扰动系统,太疏容易漏掉关键拐点
轻量脚本实现后台持续记录
下面这个 Bash 脚本可长期运行,自动记录时间戳、RSS 和进程名到日志文件:
#!/bin/bash
PID=$1
OUTFILE=${2:-"mem_trend_$(date +%s).log"}
echo "# timestamp(pid:$PID) rss_kb comm" > "$OUTFILE"
while kill -0 $PID 2>/dev/null; do
ts=$(date +%s.%3N)
rss=$(awk '/^VmRSS:/ {print $2}' "/proc/$PID/status" 2>/dev/null)
comm=$(awk '/^Name:/ {print $2}' "/proc/$PID/status" 2>/dev/null | tr -d '\0')
[ -n "$rss" ] && echo "$ts $rss $comm" >> "$OUTFILE"
sleep 10
done
保存为 track_mem.sh,赋予执行权限后运行:./track_mem.sh 1234。生成的日志是纯文本,方便后续导入 Python 或 gnuplot 分析。
识别真实增长 vs 干扰波动
内存缓慢上升不等于泄漏,需结合业务逻辑和系统行为交叉判断:
- 观察是否单调递增:连续 30 分钟以上 RSS 持续走高,且重启后起点更高,是典型泄漏信号
- 注意周期性尖峰:如每 5 分钟一次的 RSS 跳升,可能对应定时缓存加载或批量任务
- 排除常见假阳性:glibc arena 扩展后不归还、JVM 堆外内存、GPU 显存、共享库加载等均不计入 RSS
- 对比 smaps 中 Private_Dirty:该值持续增长,比 RSS 更能确认是进程自身在泄漏
简单可视化与初步判断
原始日志可快速绘图验证趋势:
- 用 Python(pandas + matplotlib)加载日志,画出时间-RSS 折线图
- 计算每分钟平均 RSS 和最大增幅,标记异常时段(例如 5 分钟内增长超 200MB)
- 导出 Excel,添加趋势线:若 R² 接近 1 且斜率为正,需深入代码排查
- 配合 dmesg 查 OOM 记录:
dmesg | grep -i "killed process",确认是否已触发系统级保护











