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

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

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

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

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


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

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

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

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

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

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

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

@drymonfidelia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关键是工厂损失很大，你完了

#18 @skuuhui 这个主意棒，反正现在不是虚拟机就是 docker ，起两个 docker 互为备份，其中一个内存满了，就切换一下

docker 多跑几个，每个加上内存限制，自动重启

飞浆是一言难尽 你还敢随便升级

程序员：一切都太顺利了！不对，实在是过于顺利了。（开始作死）

这个很简单啊，1 台服务器搞定，开 2 个实例，Nginx 负载均衡给多个实例，做个主备切换就行，再做一个进程守护，搞定

实在是过于草台班子

太炒蛋了吧

根据 sla 赔钱

这种也线上???

可以试试进程中初始化模型，然后线程中跑推理

……没有金刚钻，别揽瓷器活。想办法找台测试机追踪一下内存使用不行吗，非要在线上搞？当然我也是站着说话不腰疼。

@sagaxu
@datocp
@fds 测试了，开发机手动调用了几次接口没问题就上线了，因为这库正常运行也要几 GB 内存就没在意