GLM-OCR连接池调优connection_pool_size设置不当会引发Connection pool is full【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR在 GLM-OCR 并行 OCR 识别过程中Connection pool is full是一个高频报错其根本原因几乎都是connection_pool_size设置不当。本文面向新手讲清连接池在识别流水线中的作用、两个默认值不同的配置位置以及三步完成的 GLM-OCR 连接池调优方法帮你快速消除该错误并稳定并发吞吐。为什么会出现 Connection pool is full 先理解 GLM-OCR 的并行识别流程版式检测对每一页文档做布局分析切分出文字、表格、公式等区域并行识别识别阶段用线程池把每个区域裁剪图并发提交给 VLM API实际并发数为min(max_workers, 128)见 glmocr/pipeline/_workers.py连接池限流所有 HTTP 请求复用同一个requests.Session池子上限pool_maxsize正是由connection_pool_size决定的见 glmocr/ocr_client.py。当并发线程数 连接池大小时线程只能排队等连接一旦等待超时urllib3 就会抛出Connection pool is full and no named connections are available。换句话说你调高了max_workers却没同步调高connection_pool_size错误就来了。快速定位connection_pool_size 在哪里配置GLM-OCR 有两种运行模式对应两个不同的connection_pool_size默认值也不一样运行模式配置路径默认值配置文件位置自建模式vLLM / SGLang / Ollamapipeline.ocr_api.connection_pool_size128glmocr/config.yamlMaaS 云端模式pipeline.maas.connection_pool_size16glmocr/config.yaml代码层默认值与之一致自建模式默认128见 glmocr/config.py其注释明确写着Should be pipeline max_workers to avoid Connection pool is fullMaaS 模式默认16见 glmocr/config.py 及 glmocr/maas_client.py。⚠️ 注意connection_pool_size不在GLMOCR_*环境变量映射表中无法用.env设置只能通过 YAML 文件或 CLI--set覆盖。配置优先级为CLI--set 关键字参数 环境变量 YAML 内置默认值见 glmocr/config.py。最快配置方法三步调好连接池第 1 步确认当前并发量。打开 glmocr/config.yaml默认max_workers: 32。记住一条铁律connection_pool_size≥max_workers且max_workers上限为 128第 2 步临时验证不改文件。运行时用--set直接覆盖例如把连接池调到 64glmocr parse document.pdf --set pipeline.ocr_api.connection_pool_size 64--set用法示例见 glmocr/cli.py。第 3 步固化为长期配置。确认有效后把pipeline.ocr_api.connection_pool_size写回 glmocr/config.yaml 即可无需重启任何服务。推荐参数组合与常见误区✅推荐组合自建模式场景max_workersconnection_pool_size说明默认配置32128开箱即用无风险想提速6464128池子 ≥ 并发即可OCR 服务吃紧出现 503161632降低并发保护服务端常见误区池子越大越好不是。连接池只是通道数服务端如 vLLM吞吐才是瓶颈。盲目拉大池子和max_workers反而更容易触发 503此时应降低max_workers而非调大池子config.yaml 中对max_workers的注释正是这个意思MaaS 模式也要调 128不必。MaaS 模式是单请求透传云端自己完成并行识别默认16足够看到 429/5xx 就怪连接池重试机制指数退避 抖动针对的是服务端限流/瞬时故障与连接池满无关别混为一谈。如何验证调优效果用一份多页 PDF 跑完整流程把日志开到 DEBUGglmocr parse big.pdf --set logging.level DEBUG健康信号不再出现PoolTimeout/Connection pool is full各区域识别结果陆续落盘若仍报池满检查是否又有人把max_workers调得超过了池子大小或并发上限 128 被其他参数放大。小结Connection pool is full 并发请求数超过了connection_pool_size设定的连接池上限一条铁律池子 ≥max_workers上限 128两个配置位置别搞混自建模式改pipeline.ocr_api.connection_pool_size默认 128MaaS 模式改pipeline.maas.connection_pool_size默认 16无法用环境变量设置优先用 CLI--set快速验证再固化到 glmocr/config.yaml。按以上步骤调优后GLM-OCR 的并行识别即可稳定跑满并发不再被连接池拖垮。【免费下载链接】GLM-OCRGLM-OCR: Accurate × Fast × Comprehensive项目地址: https://gitcode.com/GitHub_Trending/gl/GLM-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考