手贱更新了下 paddleocr，对接我们 API 的工厂停工了半小时，求助怎么解决

[drymonfidelia]

调用代码见我 3 个月前的帖 /t/1030071

3 个多月前遇到运行 4 ～ 6 小时必用完 64GB 内存的问题，我们解决方案是加到 256GB 内存，8 小时重启一次服务，但治标不治本，量变大就要更频繁重启，昨天又发了一帖问方案，发现有人建议我更新 paddleocr ，没想到问题更大了，才运行半分多钟 256GB 内存就爆了，花了半个多小时紧急回滚（不知道原来是哪个版本），对接的工厂说损失很大

[weixind]

直接上生产啊？还没正经的回滚策略。。。

[drymonfidelia]

@weixind 没想到这么简单的 API 还能崩

[rekulas]

内存泄漏？如果短时间内解决不了为啥不同时跑它 5 个服务，每隔 5-10 分钟随机重启，网关自动分流负载均衡，不就可以持续提供服务了

[sagaxu]

能随意更新版本，不测就上的服务，挂掉几个小时能有啥损失。


@drymonfidelia 就这么简单的 API ，内存泄露的问题历时 3 年都没解决。

[drymonfidelia]

@sagaxu 非互联网公司很多都是开发机器上测完直接上生产

[shm7]

paddle 你都敢随便升啊，看来是没尝过是老版本 paddlepaddle

[ttttttttt]

必须得用这 [第三方+无状态+有内存泄露] 的库，是否可以考虑用多进程或者调命令行来用？

[drymonfidelia]

@ttttttttt 这库初始化要好几秒，不能用的时候再启动

[drymonfidelia]

目前看起来只有 3 楼的方案靠谱

[AkaGhost]

@drymonfidelia 一个建议是直接开一批实例，每个实例设置一个熔断上限，调用 N 次就进入老年状态，开始拉起新实例带替代掉这个旧实例，这样应该能保持相对的泄露可控，将内存泄露的量稳定在一定水平

[yinmin]

@drymonfidelia

gunicorn 加参数 --max-requests 1000 试试

[yinmin]

@drymonfidelia 另外，如果要优化这个程序，试试 Claude 3.5 sonnet 。这种单一功能的 python 程序，提交文字需求，claude 直接给你程序源码。

[Leon6868]

可以试试 rapidocr ，用 onnx 重写的 paddleocr ，性能和稳定性可能都要好一些

[datocp]

做事太随意，不测试就搞事。
上次那人在线重建索引，导致 mssql 卡顿 3 小时，最后不忘找出原因是那台几天前的电脑锁死 mssql ，背锅了电脑，看那电脑名字也是来布暑的人。。。随便 google 一下，都说重建索引的前提是断开所有终端连接。后来用防火墙阻隔连接再重建索引，不用 1 分钟就重建完 。
那些年，
什么随便删除注册表
在生产电脑随时备份恢复数据库
安装程序乱搞
为了提高性能，删除数据库内容

这样的人员见多了。。。我都忍着不说话，只要能找到背锅的就行

[iseki]

按三楼的方法，把这块切分出去，计数/计内存重启吧。很多解决不了的（不一定是 bug ）内存泄漏都会采用这种方法（举个例子 gradle ）。
不过这次之后你们应该会优化公司流程吧，涉及到有经济损失风险的变更竟然不提前测试😵‍💫。

[ccc008]

百度好多开源的库，性能方面优化是不到位的。我们也用过一个 paddle 的模型，也是存在内存泄漏、同时运行慢一次请求要 2 到 10 秒。后面我们自己持续优化后，一次请求只要几十毫秒了。

[xian366]

@drymonfidelia paddleocr 确实有内存泄漏的问题，我也遇到过，调用 ocr 类库，内存占用随时间持续增长，直到服务器内存用尽死机。

如果你们调用的频率不是很高，可以采用调用 paddleocr cli 方式，这样用完后子进程自动杀掉了，代码改动几行即可。当然缺点也有冷启动 paddleocr cli 慢一丢丢。不过 paddleocr v3 中文识别效果确实不错。

我们持续运行了一段时间，没有再出现暴内存的情况。

[skuuhui]

换个思路，就让重启编程常态，搞一台备机，在主机上监控内存快超了，改掉中间层调用到备机。然后主机自动重启（杀掉进程？），拉起服务，再调用解析到主机。

[ma46]

我靠, 这也太草台班子了吧, 生产随便更新而且没有回滚方案

其实 paddleocr 的模型可以考虑能否将其转成 onnx 的模型, 我以前用过 paddleocr 的文字识别模型, 是将其转成 onnx 模型后再进行部署的

[dzdh]

不懂 python 问一下。为啥要把临时文件放到 /dev/shm