search

PaddlePaddle / PaddleX

All-in-One Development Tool based on PaddlePaddle（飞桨低代码开发工具）
Apache License 2.0
4.93k stars 965 forks source link

内存泄漏 #2296

Open galaxyRocky opened 1 month ago

galaxyRocky commented 1 month ago

Checklist:

  1. 查找历史相关issue寻求解答
  2. 翻阅FAQ常见问题汇总和答疑
  3. 确认bug是否在新版本里还未修复
  4. 翻阅PaddleX 部署文档说明

描述问题

部署命令：/opt/conda/bin/python -m paddlex --serve --pipeline ocr_server.yaml --device gpu:0 内存观测： 企业微信20241022-165711

复现

环境

  1. 如果您使用的是python部署方式，请提供您使用的PaddlePaddle、PaddleX版本号、Python版本号 paddle-serving-app 0.8.3 paddle-serving-client 0.2.1 paddleocr 2.9.0 paddlepaddle-gpu 3.0.0b1 paddlex 3.0.0b1

Python 3.10.13

  1. 请提供您使用的操作系统信息：Linux

  2. 请问您使用的CUDA/cuDNN的版本号是？ cuda: 12.0

Bobholamovic commented 1 month ago

你好，请问怎么样可以复现这个结果哦？

galaxyRocky commented 1 month ago

你好，请问怎么样可以复现这个结果哦？

top 观测进程本身，没有内存泄露。但是容器的监控上能看到。 我的操作是： 1、部署命令：/opt/conda/bin/python -m paddlex --serve --pipeline ocr_server.yaml --device gpu:0 2、用你们官方的调用代码，重复发送数据，不管发送同一条，还是不同的，以及不管单进程还是多进程发送，都会有相同的内存情况。

Bobholamovic commented 1 month ago

感谢反馈～ 我排查到这个问题是我们对原始图像的缓存机制导致的。辛苦 @TingquanGao 看看：

  1. 是否可以将原始图像存储在内存中，以便在result对象gc时相关的内存能够被一并回收。
  2. 考虑到生成器+上下文管理器是Python中较复杂的一种情形，我们当前的设计是否存在上下文管理器的__exit__方法未被正常调用的情况。
TingquanGao commented 1 month ago

收到，我这边看下。

galaxyRocky commented 1 month ago

循环发了一晚上请求，容器的监控上，内存已经 100%，但是并没有 oom，服务依然运行，且可以正常返回请求

Bobholamovic commented 1 month ago

在微信群已回复～

sunzx8 commented 1 week ago

在微信群已回复～

您好，可以在这里同步一下吗？我也遇到了这个问题

Bobholamovic commented 1 week ago

感谢反馈～ 我排查到这个问题是我们对原始图像的缓存机制导致的。辛苦 @TingquanGao 看看：

  1. 是否可以将原始图像存储在内存中，以便在result对象gc时相关的内存能够被一并回收。
  2. 考虑到生成器+上下文管理器是Python中较复杂的一种情形，我们当前的设计是否存在上下文管理器的__exit__方法未被正常调用的情况。

就是这个原因哈