Python 也有内存泄漏？

admin
admin
admin
139164
文章
114
评论
2024年10月21日18:50:39评论8 views字数 4154阅读13分50秒阅读模式
Python 也有内存泄漏？
1. 背景
前段时间接手了一个边缘视觉识别的项目，大功能已经开发的差不多了，主要是需要是优化一些性能问题。其中比较突出的内存泄漏的问题，而且不止一处，有些比较有代表性，可以总结一下。
为了更好地可视化内存占用的变化，将项目占用的机器资源指指标上报到 Prometheus，项目一开始的情况如下（横轴-时间，纵轴-内存）：
Python 也有内存泄漏？
可以看到内存在不断的增长，到最后 OOM 了，服务重启，确实有内存泄漏的情况。
2. 工具
  • Memray
  • Tracemalloc
  • Memory_profiler
3. 查看是否有线程数泄漏
使用 Memray 查看线程的占用情况，可以看到线程数一直在增长
Python 也有内存泄漏？
Python 也有内存泄漏？
Python 也有内存泄漏？
新增加的线程大部分都是 sockerserver，我查了下，大概率是 SSE 的连接没有释放掉，再看看代码：
   def sse_server(self):        def streamer():            while True:                try:                    # do yield                    ...                except:                    ...        response = Response(streamer(), mimetype="text/event-stream")        response.headers["Cache-Control"] = "no-cache"        response.headers["X-Accel-Buffering"] = "no"        return response
如上图看到：try 在 while 里面，如果遇到所有异常，会被 try catch 到，循环并不会结束，如果没有适当的退出机制，这会导致永远也无法结束，资源一直没释放。
解决方案，考虑更全面一些，除了特定的异常，其他的异常都必须中断循环。
def sse_server(self):    def streamer():        while True:            try:                # 生成事件数据                data = yield                # 这里可以添加生成数据的逻辑            except AllowException:                # 期待的，能继续生成数据的异常                continue            except GeneratorExit:                # 客户端连接关闭时退出生成器                break            except Exception as e:                # 其他异常处理                break    def generate():        for message in streamer():            if message:                yield f"data: {message}nn"    response = Response(generate(), mimetype="text/event-stream")    response.headers["Cache-Control"] = "no-cache"    response.headers["X-Accel-Buffering"] = "no"    return response
本以为已经解决了内存泄漏的问题，没想到一看 prom，内存还是在一直增长，说明还有其他的内存泄漏。
4. 检查依赖 C++ 动态库的代码
这个项目是需要对视频流解码，其中也用到了 ffmpeg 的库，有一部分代码是使用 C++ 写的，这部分需要手动管理内存，这部分管理不好，也会导致内存泄漏。
我把所有申请到内存的都看了一遍，结果发现有网络初始化，没有对应的网络释放，avformat_network_init 和 avformat_network_deinit 函数是成对使用的，avformat_network_deinit 用于关闭网络模块并释放相关资源。如果在程序结束时没有调用这个函数，可能会导致与网络相关的资源没有被正确释放，从而产生内存泄漏。
但这个是在网络不稳定的情况下，一直频繁地断开，重新创建解码线程，内存泄漏才会显现出来，一般在内部，网络稳定的情况下，问题不大。果然，编译完重新跑，内存泄漏还没有解决。
5. 使用 tracemalloc 查看内存增长
import tracemalloctracemalloc.start()# ... 开始程序 ...snapshot1 = tracemalloc.take_snapshot()# ... 怀疑有泄漏的代码 ...snapshot2 = tracemalloc.take_snapshot()top_stats = snapshot2.compare_to(snapshot1, 'lineno')for stat in top_stats[:10]:    print(stat)
跑了2个小时后，发现某一行的内存一直没有释放，count 和 size 一直在增加，并没有释放的迹象。
analyzer_arm_rknn_4.py:397: size=3318 KiB (+18.6 MB), count=39426 (+10), average=501 K

‍

所以读了这部分相关的代码，代码的逻辑大概是：拷贝一张图片，并且再一张图片画框，然后将这张图片发送给上级系统，并将这张图片和信息持久化到自研的文件系统中。
看调试信息，大概率是这张图片内存没有被释放，在 Python 中，如果没有被释放，说明这张图片的引用计数大于 0，一直被某个地方引用到了。过程我就不细聊了，最终发现下面的代码有问题：
    def write_disk(self, force=False):        t = time.time()        if self.buffer["total_size"] == 0:            ...        elif self.buffer["total_size"] > BUFFER_SIZE or t - self.buffer["t"] > BUFFER_INTERVAL or force:            ...            self.buffer["t"] = t            self.buffer["total_size"] = 0            try:                f = open(self.save_path, "rb+")                for item in self.buffer["tasks"]:                    item["call"](f, *item["args"])                f.close()            except Exception:                logger.debug(traceback.format_exc())
大概意思是：这张图片先写到缓存中，在缓存超过一定大小或超过一定时间后或force参数为true时，会被写到磁盘中。虽然buffer 的时间和总大小都重新初始化了，但是占比最大的 self.buffer["tasks"] 并没有重置，这个导致图片一直被缓存到 buffer 中没有被释放。
最终封装到 reset_buffer，一起重启，避免忘记重置：
  def reset_buffer(self, t):     self.buffer["t"] = t     self.buffer["total_size"] = 0     self.buffer["tasks"] = []  def write_disk(self, force=False):        t = time.time()        if self.buffer["total_size"] == 0:            ...        elif self.buffer["total_size"] > BUFFER_SIZE or t - self.buffer["t"] > BUFFER_INTERVAL or force:            ...            try:                f = open(self.save_path, "rb+")                for item in self.buffer["tasks"]:                    item["call"](f, *item["args"])                f.close()            except Exception:                logger.debug(traceback.format_exc())            self.reset_buffer(t)
这波改完，信心满满，感觉应该彻底解决了。重新跑    了大概1天左右，再抽空看了 prom 内存增长曲线，曲线的斜率变低了（我的心率变高了），说明有效，但没有彻底解决，还得再查....... 
6. 重复上面的操作，再看看哪个变量没有被释放
经过一系列的排查，最终发现“嫌疑人“
video_fetcher_2.py:273: size=20.4 MB (+496 kB), count=19082 (+2)  
273 这代码也缓存相关的代码，大概逻辑是将 h264 的视频流添加到缓存，等到一定是条件再写到磁盘。
  if self.record_task:      with self.record_task_mtx:         ....         if self.record_task["now_sec"] == self.record_task["end_sec"] + 1:             # write disk             self.record_task = None
因为now_sec不一定是end_sec + 1，也可能是因为网络或者跳过的原因，导致 now_sec 大于 end_sec。所以不能严格地用 +1 来判断。
可以改成“大于等于”， 应该就解决了：
  if self.record_task:      with self.record_task_mtx:         ....         if self.record_task["now_sec"] >= self.record_task["end_sec"] + 1:             # write disk             self.record_task = None
接下来跑了1天，基本上能回到原来的位置（横轴-时间，纵轴-内存）：
Python 也有内存泄漏？
7. 总结
通过1个项目，我们可以遇到 Python 项目中的几种内存没有释放的例子：
  • Python 依赖的资源库没有释放内存
  • 使用缓存时，确认过期后没有释放内存
  • 缓存的过期条件有问题，没有触发
  • 线程没有释放
解决方案：
  • 没有 GC 的语言，一定要检查申请的资源是否有释放
  • 使用线程或者进程时，尽量使用线程池或进程池
  • 在使用缓存时，一定要检查缓存的过期条件
  • 尽量监控资源指标，尽量在上线前发现问题
当然我并没有要抨击之前写代码的人，写这篇文章只是为了总结下内存泄漏；

原文始发于微信公众号（内存泄漏）：Python 也有内存泄漏？

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年10月21日18:50:39
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出)：
                   Python 也有内存泄漏？https://cn-sec.com/archives/3292488.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉.

发表评论

匿名网友 填写信息