内存泄漏怎么确认：观察 RSS 趋势而不是感觉

发布时间:2026-07-28 13:13

## 适用场景 机器越跑越慢、内存占用只涨不跌、隔三差五要重启才舒服，这些感觉层面的描述都不足以判定内存泄漏。泄漏的严格证据来自趋势：长期观察进程常驻内存，锯齿形回落是正常缓存行为，单调爬升不见回落才是泄漏指纹。确认靠数据，不靠印象。 ## 步骤清单 第一步选定观察对象与指标：可疑进程的常驻内存集，用 pidstat 或 ps 定期采样。第二步把采样落成带时间戳的记录，最简单的方式是定时任务每小时记一行，攒够一两周数据。第三步画出来：任何表格工具都能折线化，肉眼判断形状比读数字容易得多。 ``` pidstat -r -p 24680 3600 | tee rss.log ps -o pid,rss,cmd -p 24680 while sleep 3600; do echo "$(date +%F_%T) $(awk '/VmRSS/{print $2}' /proc/24680/status)"; done >> rss.log ``` 第三步的判读标准：重启后从低位起步，随负载增长，夜间低谷回落的，是缓存策略，属正常；从低位起步，无论负载高低都匀速上爬，重启后再度重演的，基本可以定性泄漏。 ## 验证方法 定性后做交叉验证：对比同版本其他实例是否同形状，泄漏通常群体性出现；压测环境加速复现，把数周的爬升压缩到数小时，确认与请求量正相关。定位到具体进程后，交给开发侧用内存剖析工具深挖分配点。 ## 注意事项 常驻内存缓慢上涨也可能是日志缓冲、页面缓存等系统行为，判定前先看进程自己的数字而非整机。顺云云服务器的内存曲线同样适用趋势判读，监控告警建议设在增长速率而非单点水位上，后者要等很久才触发。 确认泄漏后的止血与根治要分开走：止血用计划重启，在低峰自动执行，把影响压到最小；根治要靠内存剖析，把进程的分配热点交给开发侧，常见根因是缓存无上限、集合只增不减、事件监听器未注销。修复上线后，趋势图继续跑两周，斜率归零才算结案。顺带把这次的时间线写进知识库，同类服务上线时就带上这个观测项。