尧图网页设计 
RapidOCR 容器 CPU 飙高与线程亲和报错完整排查与避坑指南【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCRRapidOCR 是基于 ONNX Runtime、OpenVINO 等多引擎的 OCR 工具包。把 RapidOCR 部署进 Docker 容器后最常见的两个性能问题是容器 CPU 占用飙到 700% 以上以及 onnxruntime 日志里出现pthread_setaffinity_np failed。本文按现象 → 原理 → 修复 → 验证把排查和修复过程走一遍。现象自查pthread_setaffinity_np 日志与 CPU 796% 指标先对号入座下面两条证据出现任意一条都可以按本文继续排查。第一条日志里冒出这样一行W pthread_setaffinity_np failed它出现在 ONNX Runtime 创建会话阶段AMD CPU 或容器环境里更常见。进程不崩、识别结果也正常但很容易让人心里没底。第二条docker stats里看到类似读数CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一个 OCR 容器吃满 7~8 个核宿主机上的其他服务会被连带拖慢。原因分析ONNX Runtime 亲和性失败与线程数失控CPU 亲和性一句话讲告诉操作系统这个线程只能跑在哪些核上。它的目的是减少线程在核之间迁移带来的数据搬运开销。为什么在容器里会失败容器通过 cgroup/cpuset 限制了进程可见的核ONNX Runtime 想绑定的核集合和容器实际被允许用的核集合对不上系统调用就返回失败日志里那行 warning 由此而来。它是警告不是错误不影响识别正确性。为什么 CPU 会飙高先看项目默认配置 config.yamlEngineConfig: onnxruntime: intra_op_num_threads: -1 inter_op_num_threads: -1-1 代表自动决定。在引擎实现 inference_engine/onnxruntime/main.py 中自动路径读取os.cpu_count()而它在容器内往往返回的是宿主机全部核数不是你的配额。打个比方容器只给你 4 核的厨房你却按 32 核招了 32 个工人全挤进来互相抢灶台。更糟的是 RapidOCR 要跑 det、cls、rec 三个模型各自都会建线程池CPU% 很容易叠加到 700% 以上。修复步骤onnxruntime 线程数设置与 docker --cpus 限制第 1 步限住 onnxruntime 线程数做什么把intra_op_num_threads/inter_op_num_threads从 -1 改成固定值。怎么做构造引擎时通过 params 传入建议取值不超过容器的 CPU 配额from rapidocr import RapidOCR params { EngineConfig.onnxruntime.intra_op_num_threads: 4, EngineConfig.onnxruntime.inter_op_num_threads: 2, } ocr RapidOCR(paramsparams) result ocr(doc.jpg)也可以直接改 config.yaml 的 EngineConfig 段效果相同。测试输入可以用一张普通文档例如项目自带的 japan.jpg怎么判断生效看进程线程数是否显著变少ps -T -p $(docker inspect -f {{.State.Pid}} rapidocr) | wc -l第 2 步设置容器 CPU 配额做什么用--cpus把容器 CPU 配额锁死让线程数和配额匹配。docker run --cpus4 --rm -it rapidocr:latest rapidocr -img doc.jpg用 compose 部署时在对应服务里加限流配置compose v2 对非 swarm 场景已支持deploy: resources: limits: cpus: 4项目自带的 docker/docker-compose.yaml 面向开发测试镜像未含 CPU 限制生产部署需自行补上。怎么判断生效docker stats里 CPU% 不再超过 400%4 核 × 100%。第 3 步处理亲和性警告可选做完第 1 步后ONNX Runtime 不再走自动亲和路径pthread_setaffinity_np failed这行在多数场景会随之消失。若仍有残留它只是 warning不必当作故障处理具体行为以 ONNX Runtime 官方文档为准。验证方法docker stats 前后对比与线程数确认对比docker stats --no-stream前后读数CPU% 应从 700% 区间降到 400% 以内。跑一次rapidocr -img doc.jpg确认识别结果仍正常返回。检查输出中的耗时字段若限线程后耗时偏高把 intra 从 4 提到 8 再测逐步找平衡点。下图是一张只含单个单词的测试图适合用来快速确认改线程数后输出是否稳定一句话收束先钉死线程数再锁容器配额CPU 问题基本就解决了。避坑提示intra 和 inter 不要都设大4 核配额下建议 intra4、inter2 起步测试再按耗时微调。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RapidOCR 容器 CPU 飙高与线程亲和报错：完整排查与避坑指南
RapidOCR 容器 CPU 飙高与线程亲和报错完整排查与避坑指南【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCRRapidOCR 是基于 ONNX Runtime、OpenVINO 等多引擎的 OCR 工具包。把 RapidOCR 部署进 Docker 容器后最常见的两个性能问题是容器 CPU 占用飙到 700% 以上以及 onnxruntime 日志里出现pthread_setaffinity_np failed。本文按现象 → 原理 → 修复 → 验证把排查和修复过程走一遍。现象自查pthread_setaffinity_np 日志与 CPU 796% 指标先对号入座下面两条证据出现任意一条都可以按本文继续排查。第一条日志里冒出这样一行W pthread_setaffinity_np failed它出现在 ONNX Runtime 创建会话阶段AMD CPU 或容器环境里更常见。进程不崩、识别结果也正常但很容易让人心里没底。第二条docker stats里看到类似读数CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一个 OCR 容器吃满 7~8 个核宿主机上的其他服务会被连带拖慢。原因分析ONNX Runtime 亲和性失败与线程数失控CPU 亲和性一句话讲告诉操作系统这个线程只能跑在哪些核上。它的目的是减少线程在核之间迁移带来的数据搬运开销。为什么在容器里会失败容器通过 cgroup/cpuset 限制了进程可见的核ONNX Runtime 想绑定的核集合和容器实际被允许用的核集合对不上系统调用就返回失败日志里那行 warning 由此而来。它是警告不是错误不影响识别正确性。为什么 CPU 会飙高先看项目默认配置 config.yamlEngineConfig: onnxruntime: intra_op_num_threads: -1 inter_op_num_threads: -1-1 代表自动决定。在引擎实现 inference_engine/onnxruntime/main.py 中自动路径读取os.cpu_count()而它在容器内往往返回的是宿主机全部核数不是你的配额。打个比方容器只给你 4 核的厨房你却按 32 核招了 32 个工人全挤进来互相抢灶台。更糟的是 RapidOCR 要跑 det、cls、rec 三个模型各自都会建线程池CPU% 很容易叠加到 700% 以上。修复步骤onnxruntime 线程数设置与 docker --cpus 限制第 1 步限住 onnxruntime 线程数做什么把intra_op_num_threads/inter_op_num_threads从 -1 改成固定值。怎么做构造引擎时通过 params 传入建议取值不超过容器的 CPU 配额from rapidocr import RapidOCR params { EngineConfig.onnxruntime.intra_op_num_threads: 4, EngineConfig.onnxruntime.inter_op_num_threads: 2, } ocr RapidOCR(paramsparams) result ocr(doc.jpg)也可以直接改 config.yaml 的 EngineConfig 段效果相同。测试输入可以用一张普通文档例如项目自带的 japan.jpg怎么判断生效看进程线程数是否显著变少ps -T -p $(docker inspect -f {{.State.Pid}} rapidocr) | wc -l第 2 步设置容器 CPU 配额做什么用--cpus把容器 CPU 配额锁死让线程数和配额匹配。docker run --cpus4 --rm -it rapidocr:latest rapidocr -img doc.jpg用 compose 部署时在对应服务里加限流配置compose v2 对非 swarm 场景已支持deploy: resources: limits: cpus: 4项目自带的 docker/docker-compose.yaml 面向开发测试镜像未含 CPU 限制生产部署需自行补上。怎么判断生效docker stats里 CPU% 不再超过 400%4 核 × 100%。第 3 步处理亲和性警告可选做完第 1 步后ONNX Runtime 不再走自动亲和路径pthread_setaffinity_np failed这行在多数场景会随之消失。若仍有残留它只是 warning不必当作故障处理具体行为以 ONNX Runtime 官方文档为准。验证方法docker stats 前后对比与线程数确认对比docker stats --no-stream前后读数CPU% 应从 700% 区间降到 400% 以内。跑一次rapidocr -img doc.jpg确认识别结果仍正常返回。检查输出中的耗时字段若限线程后耗时偏高把 intra 从 4 提到 8 再测逐步找平衡点。下图是一张只含单个单词的测试图适合用来快速确认改线程数后输出是否稳定一句话收束先钉死线程数再锁容器配额CPU 问题基本就解决了。避坑提示intra 和 inter 不要都设大4 核配额下建议 intra4、inter2 起步测试再按耗时微调。【免费下载链接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.项目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考