没有合适的资源?快使用搜索试试~ 我知道了~
填坑总结:python内存泄漏排查小技巧(csdn)————程序.pdf
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 101 浏览量
2021-12-05
18:17:54
上传
评论
收藏 422KB PDF 举报
温馨提示
试读
11页
填坑总结:python内存泄漏排查小技巧(csdn)————程序
资源推荐
资源详情
资源评论
摘要:最近服务遇到了内存泄漏问题,运维同学紧急呼叫解决,
于是在解决问题之余也系统记录了下内存泄漏问题的常见解决思
路。
本文分享自华为云社区《python 内存泄漏排查小技巧》,作者:lutianfei。
最近服务遇到了内存泄漏问题,运维同学紧急呼叫解决,于是在解决问题之余
也系统记录了下内存泄漏问题的常见解决思路。
首先搞清楚了本次问题的现象:
1. 服务在 13 号上线过一次,而从 23 号开始,出现内存不断攀升问题,达到预
警值重启实例后,攀升速度反而更快。
2. 服务分别部署在了 A、B 2 种芯片上,但除模型推理外,几乎所有的预处
理、后处理共享一套代码。而 B 芯片出现内存泄漏警告,A 芯片未出现任何异
常。
思路一:研究新旧源码及二方库依赖差异
根据以上两个条件,首先想到的是 13 号的更新引入的问题,而更新可能来自两
个方面:
1. 自研代码
2. 二方依赖代码
从上述两个角度出发:
• 一方面,分别用 Git 历史信息和 BeyondCompare 工具对比了两个版本的
源码,并重点走读了下 A、B 两款芯片代码单独处理的部分,均未发现任
何异常。
• 另一方面,通过 pip list 命令对比两个镜像包中的二方包,发现仅有
pytz 时区工具依赖的版本有变化。
经过研究分析,认为此包导致的内存泄漏的可能性不大,因此暂且放
下。
至此,通过研究新旧版本源码变化找出内存泄漏问题这条路,似乎有点走不下
去了。
思路二:监测新旧版本内存变化差异
目前 python 常用的内存检测工具有 pympler、objgraph、tracemalloc 等。
首先,通过 objgraph 工具,对新旧服务中的 TOP50 变量类型进行了观察统计
objraph 常用命令如下:
# 全局类型数量
objgraph.show_most_common_types(limit=50)
# 增量变化
objgraph.show_growth(limit=30)
这里为了更好的观测变化曲线,我简单做了个封装,使数据直接输出到了 csv
文件以便观察。
stats = objgraph.most_common_types(limit=50)
stats_path = "./types_stats.csv"
tmp_dict = dict(stats)
req_time = time.strftime("%Y-%m-%d %H:%M:%S", time.localtime())
tmp_dict['req_time'] = req_time
df = pd.DataFrame.from_dict(tmp_dict, orient='index').T
if os.path.exists(stats_path):
df.to_csv(stats_path, mode='a', header=True, index=False)
else:
df.to_csv(stats_path, index=False)
如下图所示,用一批图片在新旧两个版本上跑了 1 个小时,一切稳如老狗,各
类型的数量没有一丝波澜。
此时,想到自己一般在转测或上线前都会将一批异常格式的图片拿来做个边界
验证。
虽然这些异常,测试同学上线前肯定都已经验证过了,但死马当成活马医就顺
手拿来测了一下。
平静数据就此被打破了,如下图红框所示:dict、function、method、tuple、
traceback 等重要类型的数量开始不断攀升。
剩余10页未读,继续阅读
资源评论
一诺网络技术
- 粉丝: 0
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功