mineru解析某些报告会失败甚至卡死后台服务

[Nightmaer]

使用的过程中发现有些报告不能正常解析？后台开MinerU服务的时候请求调用就卡住崩掉了，在线解析也是卡住不动了，想请问一下这是因为什么造成的呢，之前没遇到过，最近频繁遇到这种情况，一开始以为是机子有问题，概率性出现这种问题，现在又碰到了，结果发现是某些报告没有办法解析。

如果是无法解析的情况下应该直接返回错误信息或直接raise报错才对啊，它把mineru-api接口给直接卡死不动了，迫不得已得手动重启它再继续使用，已经被该问题困扰了一段时间了，来社区寻求帮助！！！

[dosubot[bot]]

你遇到的MinerU解析报告卡死/崩溃问题，是社区已知的高频现象，主要技术原因包括：

1. 大文件或高并发导致内存峰值过高，尤其是一次性加载和推理全部PDF页面时，容易触发内存溢出或死锁，进程被卡死，API层无法及时返回错误，只能等进程被杀或重启服务才能恢复。参考
2. 底层pypdfium2库线程不安全，多线程/高并发下易资源泄漏或死锁，官方建议用多进程并发，避免多线程。参考
3. 部分模型推理代码异常未捕获，如表格识别模型遇到无单元格时IndexError、OCR模型兼容性问题等，直接导致进程崩溃或假死，需升级到2.7.0+或切换hybrid/pipeline后端。参考
4. API接口虽然有try/except包裹，但aio_do_parse/do_parse/doc_analyze等核心流程缺乏超时和细粒度异常处理，一旦底层阻塞或死循环，API层无法主动中断，只能等进程被杀或重启。参考
5. vlm-http-client等后端批处理机制容错性差，只要一页失败整批终止，建议逐页try/except处理，提升容错性。参考

为什么不是直接报错而是卡死？
因为底层推理流程没有超时/中断机制，且部分异常未被捕获，导致FastAPI主流程一直await卡住，无法及时返回错误响应。部分资源（如GPU显存、文件句柄）未及时释放，服务只能靠重启恢复。参考

推荐解决方案：

• 优先升级MinerU到2.7.0+，新版本修复了表格识别等已知bug，并优化了并发和内存管理。参考
• 部署建议优先用Docker，避免Windows+conda等环境的多进程兼容性问题。参考
• 大文件用--start/--end/--max-convert-pages参数分批处理，降低单次内存压力。参考
• 并发场景下用MINERU_API_MAX_CONCURRENT_REQUESTS、MINERU_VIRTUAL_VRAM_SIZE等环境变量限制并发和显存（2.6.4+生效）。参考
• 如无法升级或改代码，建议定期重启服务、降低并发、切换pipeline/hybrid后端、监控系统资源。
• 代码层面可在doc_analyze等关键步骤加try/except和详细日志，或逐页try/except处理，提升容错性。参考
• 开启debug日志，定位具体卡死点，必要时贴出日志或问题PDF便于进一步分析。参考

如需代码层面的异常处理示例或具体参数配置，可补充说明你的MinerU版本和部署方式。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[finch-xu]

docker compose 部署的vllm mineru api有健康检查的接口和方式吗？目前查看接口只有file_parse，如何监控到mineru卡死的状态呢？

[CUsopp]

2.7.5也出现了卡死的状态。。。。。。
现象是 GPU 一动不动，但是docker 服务状态正常变化，是不是因为偶然达到了内存峰值导致的？

[Chinaniu]

昇腾系统910b，npu模式，ragflow-调用minerU进行http-client解析pdf文档的时候，也出现了，mineru-api解析卡死的现象，应该如何解决这个问题