这是一个创建于 135 天前的主题，其中的信息可能已经有所发展或是发生改变。
调用代码见我 3 个月前的帖 /t/1030071
3 个多月前遇到运行 4 ～ 6 小时必用完 64GB 内存的问题，我们解决方案是加到 256GB 内存，8 小时重启一次服务，但治标不治本，量变大就要更频繁重启，昨天又发了一帖问方案，发现有人建议我更新 paddleocr ，没想到问题更大了，才运行半分多钟 256GB 内存就爆了，花了半个多小时紧急回滚（不知道原来是哪个版本），对接的工厂说损失很大
3 个多月前遇到运行 4 ～ 6 小时必用完 64GB 内存的问题，我们解决方案是加到 256GB 内存，8 小时重启一次服务，但治标不治本，量变大就要更频繁重启，昨天又发了一帖问方案，发现有人建议我更新 paddleocr ，没想到问题更大了，才运行半分多钟 256GB 内存就爆了，花了半个多小时紧急回滚（不知道原来是哪个版本），对接的工厂说损失很大
33 条回复 • 2024-07-25 03:40:58 +08:00
 |
1
weixind 135 天前
直接上生产啊？还没正经的回滚策略。。。
|
 |
2
drymonfidelia OP @weixind 没想到这么简单的 API 还能崩
|
 |
3
rekulas 135 天前  11
内存泄漏？如果短时间内解决不了为啥不同时跑它 5 个服务，每隔 5-10 分钟随机重启，网关自动分流负载均衡，不就可以持续提供服务了
|
 |
4
sagaxu 135 天前
|
|
5
drymonfidelia OP @sagaxu 非互联网公司很多都是开发机器上测完直接上生产
|
 |
6
shm7 135 天前 1
paddle 你都敢随便升啊，看来是没尝过是老版本 paddlepaddle
|
 |
7
ttttttttt 135 天前
必须得用这 [第三方+无状态+有内存泄露] 的库，是否可以考虑用多进程或者调命令行来用？
|
|
8
drymonfidelia OP @ttttttttt 这库初始化要好几秒，不能用的时候再启动
|
|
9
drymonfidelia OP 1
目前看起来只有 3 楼的方案靠谱
|
 |
10
AkaGhost 135 天前 1
@drymonfidelia 一个建议是直接开一批实例，每个实例设置一个熔断上限，调用 N 次就进入老年状态，开始拉起新实例带替代掉这个旧实例，这样应该能保持相对的泄露可控，将内存泄露的量稳定在一定水平
|
 |
11
yinmin 135 天前 1
|
|
12
yinmin 135 天前
@drymonfidelia 另外，如果要优化这个程序，试试 Claude 3.5 sonnet 。这种单一功能的 python 程序，提交文字需求，claude 直接给你程序源码。
|
 |
13
Leon6868 135 天前
可以试试 rapidocr ，用 onnx 重写的 paddleocr ，性能和稳定性可能都要好一些
|
 |
14
datocp 135 天前 via Android
做事太随意，不测试就搞事。
上次那人在线重建索引，导致 mssql 卡顿 3 小时，最后不忘找出原因是那台几天前的电脑锁死 mssql ，背锅了电脑，看那电脑名字也是来布暑的人。。。随便 google 一下，都说重建索引的前提是断开所有终端连接。后来用防火墙阻隔连接再重建索引，不用 1 分钟就重建完 。 那些年， 什么随便删除注册表 在生产电脑随时备份恢复数据库 安装程序乱搞 为了提高性能，删除数据库内容 这样的人员见多了。。。我都忍着不说话，只要能找到背锅的就行 |
 |
15
iseki 135 天前 via Android
按三楼的方法，把这块切分出去，计数/计内存重启吧。很多解决不了的（不一定是 bug ）内存泄漏都会采用这种方法（举个例子 gradle ）。
不过这次之后你们应该会优化公司流程吧，涉及到有经济损失风险的变更竟然不提前测试😵💫。 |
 |
16
ccc008 135 天前
百度好多开源的库，性能方面优化是不到位的。我们也用过一个 paddle 的模型，也是存在内存泄漏、同时运行慢一次请求要 2 到 10 秒。后面我们自己持续优化后，一次请求只要几十毫秒了。
|
 |
17
xian366 135 天前 via Android
@drymonfidelia paddleocr 确实有内存泄漏的问题，我也遇到过，调用 ocr 类库，内存占用随时间持续增长，直到服务器内存用尽死机。
如果你们调用的频率不是很高，可以采用调用 paddleocr cli 方式，这样用完后子进程自动杀掉了，代码改动几行即可。当然缺点也有冷启动 paddleocr cli 慢一丢丢。不过 paddleocr v3 中文识别效果确实不错。 我们持续运行了一段时间，没有再出现暴内存的情况。 |
 |
18
skuuhui 135 天前
换个思路，就让重启编程常态，搞一台备机，在主机上监控内存快超了，改掉中间层调用到备机。然后主机自动重启（杀掉进程？），拉起服务，再调用解析到主机。
|
 |
19
ma46 135 天前
我靠, 这也太草台班子了吧, 生产随便更新而且没有回滚方案
其实 paddleocr 的模型可以考虑能否将其转成 onnx 的模型, 我以前用过 paddleocr 的文字识别模型, 是将其转成 onnx 模型后再进行部署的 |
 |
20
dzdh 135 天前
不懂 python 问一下。为啥要把临时文件放到 /dev/shm
|
 |
21
LiuJiang 135 天前
关键是工厂损失很大，你完了
|
 |
23
ersic 135 天前
docker 多跑几个，每个加上内存限制，自动重启
|
 |
24
seu 135 天前
飞浆是一言难尽 你还敢随便升级
|
 |
25
ChrisFreeMan 135 天前 1
程序员：一切都太顺利了！不对，实在是过于顺利了。（开始作死）
|
 |
26
zuiyue123 135 天前
这个很简单啊，1 台服务器搞定，开 2 个实例，Nginx 负载均衡给多个实例，做个主备切换就行，再做一个进程守护，搞定
|
 |
27
shuax 135 天前
实在是过于草台班子
|
 |
28
lihai1911 135 天前
太炒蛋了吧
|
 |
29
wushenlun 135 天前 via Android
根据 sla 赔钱
|
 |
30
goxxoo 134 天前
这种也线上???
|
 |
31
woscaizi 134 天前
可以试试进程中初始化模型，然后线程中跑推理
|
 |
32
fds 134 天前
……没有金刚钻，别揽瓷器活。想办法找台测试机追踪一下内存使用不行吗，非要在线上搞？当然我也是站着说话不腰疼。
|
|
33
drymonfidelia OP |
Select Language