多并发处理PDF偶发502网关错误

[minglu6]

🔎 Search before asking | 提交之前请先搜索

• I have searched the MinerU Readme and found no similar bug report.
• I have searched the MinerU Issues and found no similar bug report.
• I have searched the MinerU Discussions and found no similar bug report.

🤖 Consult the online AI assistant for assistance | 在线 AI 助手咨询

• I have consulted the online AI assistant but was unable to obtain a solution to the issue.

Description of the bug | 错误描述

当同时处理3个文件及以上数量的的时候，会偶发下面错误

How to reproduce the bug | 如何复现

miner-sglang版本是2.1.9
服务器是 Ubuntu22.04 显卡是4090，cuda版本是12.8
当前使用的配置是：
dp-size:2 mem-fraction-static：0.7
测试文件大小为60M
同时处理3个文件的时候会偶发此错误

Operating System Mode | 操作系统类型

Linux

Operating System Version| 操作系统版本

Ubuntu22.04

Python version | Python 版本

3.10

Software version | 软件版本 (mineru --version)

No response

Device mode | 设备模式

cuda

[dosubot]

Hi @minglu6! I'm Dosu and I’m helping the MinerU team.

你遇到的502网关错误在多并发处理PDF时，主要原因是后端服务（如sglang/miner-sglang）在高并发或大文件场景下资源耗尽或被操作系统kill，导致HTTP返回502和空响应，进而引发JSON解析报错。这类问题在社区和代码实现中有较多类似反馈和分析，核心点如下：

1. 并发模型建议：MinerU的pipeline（如pipeline_result_to_middle_json）本身是串行、非线程安全的，PyTorch的CUDA模型不能多线程/多协程并发访问，否则容易引发底层CUDA错误或进程崩溃。官方推荐用多进程/多worker方式，每个进程独立初始化模型和CUDA上下文，避免线程并发访问同一模型或设备参考。

2. 内存和显存压力：大文件（如60MB PDF）并发处理时，容易导致GPU显存或系统内存溢出（OOM），进而被操作系统kill掉worker进程，客户端收到502。建议尝试降低--mem-fraction-static（如0.3~0.4），减少单worker占用的显存，避免OOM参考。

3. 批量参数调优：MinerU的批量推理参数如MINERU_MIN_BATCH_INFERENCE_SIZE（默认384）和MINERU_VIRTUAL_VRAM_SIZE可通过环境变量调整，影响每批处理的页数和显存分配。单卡环境下建议优先调大OCR的batch size（rec_batch_num，需在代码或命令行指定），提升显卡利用率，但要用nvidia-smi监控，避免OOM参考。

4. 并发控制：sglang-client的并发是通过asyncio.Semaphore控制的，默认最大并发100。高并发下后端服务容易被压垮，建议适当降低并发量，或分批处理（如每批20-50个PDF），遇到错误时回退为单文件处理参考。

5. 监控与排查：502错误通常后端日志不会有详细报错，建议重点关注系统级日志（dmesg、docker logs、nvidia-smi），定位是否有OOM或进程被kill的记录参考。

6. 版本与优化：近期有PR对批量参数和性能做了优化，建议关注最新版本的MinerU和miner-sglang，部分批量和性能参数已做调整参考。

建议操作：

• 优先用多进程/多worker方式并发，每个进程独立初始化模型和CUDA上下文，避免线程并发。
• 降低--mem-fraction-static参数，减少单worker显存压力。
• 调整批量参数（如MINERU_MIN_BATCH_INFERENCE_SIZE、rec_batch_num），并用nvidia-smi监控显存。
• 降低并发量，分批处理PDF，遇到502时回退单文件处理。
• 检查系统内存和容器内存限制，避免被宿主机OOM killer杀死。
• 关注系统日志定位OOM或进程崩溃原因。

如需进一步定位，建议收集出错时的dmesg、docker logs和nvidia-smi截图，便于分析资源瓶颈。

To reply, just mention @dosu.

---

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

[minglu6]

实时监控了显卡内存占用，处理过程中最大到93%，应该没有OOM

[dosubot]

你说得对，显卡显存没满通常不会直接OOM，但502错误还有其他常见原因，比如系统内存（RAM）或Docker容器内存不足、进程数/文件句柄数限制、后端服务超时等。社区有类似案例，很多是因为系统RAM或容器内存不够、sglang后端超时、或进程被宿主机OOM killer杀死导致502和空响应（即使GPU没满）参考1 参考2 参考3。

建议你：

• 并发处理时同步监控系统RAM和swap占用（如htop、free -h），不是只看GPU。
• 检查dmesg、docker logs等系统日志，是否有OOM killer或进程被kill的记录。
• 检查sglang后端日志，确认是否有超时（默认300秒）或崩溃。
• 如用容器，确认Docker内存/ulimit设置是否足够，建议物理内存128GB以上用于大批量/大文件参考。
• 可以尝试降低mem-fraction-static参数、减小并发量或分批处理，或调大MINERU_MIN_BATCH_INFERENCE_SIZE和--max_concurrency参数（但要注意别让后端压力过大）参考。

如果还有疑问，可以贴下系统内存监控和相关日志片段，方便进一步定位。

To reply, just mention @dosu.

---

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