填坑总结:python内存泄漏排查小技巧

2021年11月24日 阅读数:4
这篇文章主要向大家介绍填坑总结:python内存泄漏排查小技巧,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。
摘要:最近服务遇到了内存泄漏问题,运维同窗紧急呼叫解决,因而在解决问题之余也系统记录了下内存泄漏问题的常看法决思路。

本文分享自华为云社区《python内存泄漏排查小技巧》,做者:lutianfei。html

最近服务遇到了内存泄漏问题,运维同窗紧急呼叫解决,因而在解决问题之余也系统记录了下内存泄漏问题的常看法决思路。python

首先搞清楚了本次问题的现象:git

1. 服务在13号上线过一次,而从23号开始,出现内存不断攀升问题,达到预警值重启实例后,攀升速度反而更快。github

2. 服务分别部署在了A、B 2种芯片上,但除模型推理外,几乎全部的预处理、后处理共享一套代码。而B芯片出现内存泄漏警告,A芯片未出现任何异常。segmentfault

思路一:研究新旧源码及二方库依赖差别

根据以上两个条件,首先想到的是13号的更新引入的问题,而更新可能来自两个方面:缓存

  1. 自研代码
  2. 二方依赖代码

从上述两个角度出发:app

  • 一方面,分别用Git历史信息和BeyondCompare工具对比了两个版本的源码,并重点走读了下A、B两款芯片代码单独处理的部分,均未发现任何异常。
  • 另外一方面,经过pip list命令对比两个镜像包中的二方包,发现仅有pytz时区工具依赖的版本有变化。
    通过研究分析,认为此包致使的内存泄漏的可能性不大,所以暂且放下。

至此,经过研究新旧版本源码变化找出内存泄漏问题这条路,彷佛有点走不下去了。运维

思路二:监测新旧版本内存变化差别

目前python经常使用的内存检测工具备pymplerobjgraphtracemalloc 等。工具

首先,经过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个小时,一切稳如老狗,各种型的数量没有一丝波澜。

此时,想到本身通常在转测或上线前都会将一批异常格式的图片拿来作个边界验证。

虽然这些异常,测试同窗上线前确定都已经验证过了,但死马当成活马医就顺手拿来测了一下。

平静数据就此被打破了,以下图红框所示:dictfunctionmethodtupletraceback等重要类型的数量开始不断攀升。

而此时镜像内存亦不断增长且毫无收敛迹象。

由此,虽没法确认是否为线上问题,但至少定位出了一个bug。而此时回头检查日志,发现了一个奇怪的现象:
正常状况下特殊图片致使的异常,日志应该输出以下信息,即check_image_type方法在异常栈中只会打印一次。

但现状是check_image_type方法循环重复打印了屡次,且重复次数随着测试次数在一块儿变多。

从新研究了这块儿的异常处理代码。

异常声明以下:

抛异常代码以下:

问题所在

思考后大概想清楚了问题根源:

这里每一个异常实例至关于被定义成了一个全局变量,而在抛异常的时候,抛出的也正是这个全局变量。当此全局变量被压入异常栈处理完成以后,也并不会被回收。

所以随着错误格式图片调用的不断增多,异常栈中的信息也会不断增多。并且因为异常中还包含着请求图片信息,所以内存会呈MB级别的增长。

但这部分代码上线已久,线上若是真的也是这里致使的问题,为什么以前没有任何问题,并且为什么在A芯片上也没有出现任何问题?

带着以上两个疑问,咱们作了两个验证:

首先,确认了以前的版本以及A芯片上一样会出现此问题。

其次,咱们查看了线上的调用记录,发现最近恰好新接入了一个客户,并且出现了大量使用相似问题的图片调用某局点(该局点大部分为B芯片)服务的现象。咱们找了些线上实例,从日志中也观测到了一样的现象。

由此,以上疑问基本获得了解释,修复此bug后,内存溢出问题再也不出现。

进阶思路

讲道理,问题解决到这个地步彷佛能够收工了。但我问了本身一个问题,若是当初没有打印这一行日志,或者开发人员偷懒没有把异常栈所有打出来,那应该如何去定位?

带着这样的问题我继续研究了下objgraphpympler 工具。

前文已经定位到了在异常图片状况下会出现内存泄漏,所以重点来看下此时有哪些异样状况:

经过以下命令,咱们能够看到每次异常出现时,内存中都增长了哪些变量以及增长的内存状况。

  1. 使用objgraph工具
    objgraph.show_growth(limit=20)

  1. 使用pympler工具
from pympler import tracker
tr = tracker.SummaryTracker()
tr.print_diff()

经过以下代码,能够打印出这些新增变量来自哪些引用,以便进一步分析。

gth = objgraph.growth(limit=20)
for gt in gth:
    logger.info("growth type:%s, count:%s, growth:%s" % (gt[0], gt[1], gt[2]))
    if gt[2] > 100 or gt[1] > 300:
        continue
    objgraph.show_backrefs(objgraph.by_type(gt[0])[0], max_depth=10, too_many=5,
                           filename="./dots/%s_backrefs.dot" % gt[0])
    objgraph.show_refs(objgraph.by_type(gt[0])[0], max_depth=10, too_many=5,
                       filename="./dots/%s_refs.dot" % gt[0])
    objgraph.show_chain(
        objgraph.find_backref_chain(objgraph.by_type(gt[0])[0], objgraph.is_proper_module),
        filename="./dots/%s_chain.dot" % gt[0]
    )

经过graphvizdot工具,对上面生产的graph格式数据转换成以下图片:

dot -Tpng xxx.dot -o xxx.png

这里,因为dict、list、frame、tuple、method等基本类型数量太多,观测较难,所以这里先作了过滤。

内存新增的ImageReqWrapper的调用链

内存新增的traceback的调用链:

虽然带着前面的先验知识,使咱们很天然的就关注到了traceback和其对应的IMAGE_FORMAT_EXCEPTION异常。
但经过思考为什么上面这些本应在服务调用结束后就被回收的变量却没有被回收,尤为是全部的traceback变量在被IMAGE_FORMAT_EXCEPTION异常调用后就没法回收等这些现象;同时再作一些小实验,相信很快就能定位到问题根源。

另,关于 python3中 缓存Exception致使的内存泄漏问题,知乎有一篇讲的相对更清楚一点:https://zhuanlan.zhihu.com/p/38600861

至此,咱们能够得出结论以下:

因为抛出的异常没法回收,致使对应的异常栈、请求体等变量都没法被回收,而请求体中因为包含图片信息所以每次这类请求都会致使MB级别的内存泄漏。

另外,研究过程当中还发现python3自带了一个内存分析工具tracemalloc,经过以下代码就能够观察代码行与内存之间的关系,虽然可能未必精确,但也能大概提供一些线索。

import tracemalloc

tracemalloc.start(25)
snapshot = tracemalloc.take_snapshot()
global snapshot
gc.collect()
snapshot1 = tracemalloc.take_snapshot()
top_stats = snapshot1.compare_to(snapshot, 'lineno')
logger.warning("[ Top 20 differences ]")
for stat in top_stats[:20]:
    if stat.size_diff < 0:
        continue
    logger.warning(stat)
snapshot = tracemalloc.take_snapshot()

参考文章

https://testerhome.com/articles/19870?order_by=created_at&
https://blog.51cto.com/u_3423936/3019476
https://segmentfault.com/a/1190000038277797
https://www.cnblogs.com/zzbj/p/13532156.html
https://drmingdrmer.github.io/tech/programming/2017/05/06/python-mem.html
https://zhuanlan.zhihu.com/p/38600861

 

点击关注,第一时间了解华为云新鲜技术~