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/RapidOCR把 OCR 服务塞进 K8s Pod限了 2 个核宿主机是 64 核 AMD EPYC。结果监控里 CPU 飙到 796%日志里还刷pthread_setaffinity_np failed。推理结果是对的机器却像没刹住车。这套排查链路适用于 RapidOCR 容器 CPU 异常这类问题。环境差异全景同一份代码不同的看见代码没变变的只是 ONNX Runtime 启动时看见了多少资源运行环境默认线程数来源CPU 亲和设置典型表现裸机os.cpu_count()主机核数一般成功线程吃满本机符合预期Docker 不限核同上看到主机全核一般成功宿主机 CPU 曲线被拉满Docker--cpus限核同上仍看到主机全核视虚拟化而定超卖700% 飙高虚拟化/AMD 宿主同上常报pthread_setaffinity_np failed报错 线程乱跑结论先立住问题不出在推理出在线程数怎么定的和容器到底给了几个核。逐层诊断先看线程数怎么定的默认配置 python/rapidocr/config.yaml 里intra_op_num_threads和inter_op_num_threads都是 -1。在 python/rapidocr/inference_engine/onnxruntime/main.py 里-1 等于不设置交给 ONNX Runtime 自动决定——它的依据是os.cpu_count()。更要命的是 RapidOCR 一次跑检测、分类、识别三个 session32 核宿主机上就是三份线程池一个请求能拉出上百个工作线程。再查容器到底给了几个核验证方法就一条对比代码以为有几个核和容器实际给了几个核。cat /sys/fs/cgroup/cpu.max # 输出如 200000 100000即限 2 核如果前者是 64、后者是 296 个线程挤 2 个核796% 就是这么来的。os.cpu_count()在容器里读的是宿主机核数不认 cgroup 限额——这是整条链路里最容易被忽略的一环。亲和性报错单独看pthread_setaffinity_np failed是 ONNX Runtime 尝试把线程钉到指定核、被内核拒绝。它不致命失败后线程不绑核由调度器随便放推理照常出结果。但它在提醒你——这台 AMD/虚拟化宿主的自动绑核走不通别再指望自动行为线程数得自己定死。调优实操三个参数怎么填参数推荐值为什么是这个值intra_op_num_threads 容器核数如--cpus2就填 2与 cgroup 限额对齐线程不再超卖inter_op_num_threads1OCR 单请求串行算子间没并行可挖arena_extend_strategy保持默认kSameAsRequested内存池按请求量增长不额外吃内存启动时直接传参即可RapidOCR(params{EngineConfig.onnxruntime.intra_op_num_threads: 2, EngineConfig.onnxruntime.inter_op_num_threads: 1})容器侧配合docker run --cpus2 ...K8s 里 requests 与 limits 都写成 2别让 Pod 漂在主机核数上。避坑清单容器不限核就启动 → 线程按主机核数开CPU 直接 700% →--cpus写死。把宿主机nproc当线程数传进 2 核容器 → 照样超卖 → 传容器实际核数。以为参数生效了实际 -1 默认值仍走自动模式 → 显式填正整数。无视pthread_setaffinity_np failed→ 线程乱跳p95 延迟抖 → 显式钉线程数别靠自动绑核。高 intra 线程叠加开启enable_cpu_mem_arena→ 内存跟着线程数膨胀 → 限线程后顺手把 arena 关掉。【免费下载链接】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/RapidOCR把 OCR 服务塞进 K8s Pod限了 2 个核宿主机是 64 核 AMD EPYC。结果监控里 CPU 飙到 796%日志里还刷pthread_setaffinity_np failed。推理结果是对的机器却像没刹住车。这套排查链路适用于 RapidOCR 容器 CPU 异常这类问题。环境差异全景同一份代码不同的看见代码没变变的只是 ONNX Runtime 启动时看见了多少资源运行环境默认线程数来源CPU 亲和设置典型表现裸机os.cpu_count()主机核数一般成功线程吃满本机符合预期Docker 不限核同上看到主机全核一般成功宿主机 CPU 曲线被拉满Docker--cpus限核同上仍看到主机全核视虚拟化而定超卖700% 飙高虚拟化/AMD 宿主同上常报pthread_setaffinity_np failed报错 线程乱跑结论先立住问题不出在推理出在线程数怎么定的和容器到底给了几个核。逐层诊断先看线程数怎么定的默认配置 python/rapidocr/config.yaml 里intra_op_num_threads和inter_op_num_threads都是 -1。在 python/rapidocr/inference_engine/onnxruntime/main.py 里-1 等于不设置交给 ONNX Runtime 自动决定——它的依据是os.cpu_count()。更要命的是 RapidOCR 一次跑检测、分类、识别三个 session32 核宿主机上就是三份线程池一个请求能拉出上百个工作线程。再查容器到底给了几个核验证方法就一条对比代码以为有几个核和容器实际给了几个核。cat /sys/fs/cgroup/cpu.max # 输出如 200000 100000即限 2 核如果前者是 64、后者是 296 个线程挤 2 个核796% 就是这么来的。os.cpu_count()在容器里读的是宿主机核数不认 cgroup 限额——这是整条链路里最容易被忽略的一环。亲和性报错单独看pthread_setaffinity_np failed是 ONNX Runtime 尝试把线程钉到指定核、被内核拒绝。它不致命失败后线程不绑核由调度器随便放推理照常出结果。但它在提醒你——这台 AMD/虚拟化宿主的自动绑核走不通别再指望自动行为线程数得自己定死。调优实操三个参数怎么填参数推荐值为什么是这个值intra_op_num_threads 容器核数如--cpus2就填 2与 cgroup 限额对齐线程不再超卖inter_op_num_threads1OCR 单请求串行算子间没并行可挖arena_extend_strategy保持默认kSameAsRequested内存池按请求量增长不额外吃内存启动时直接传参即可RapidOCR(params{EngineConfig.onnxruntime.intra_op_num_threads: 2, EngineConfig.onnxruntime.inter_op_num_threads: 1})容器侧配合docker run --cpus2 ...K8s 里 requests 与 limits 都写成 2别让 Pod 漂在主机核数上。避坑清单容器不限核就启动 → 线程按主机核数开CPU 直接 700% →--cpus写死。把宿主机nproc当线程数传进 2 核容器 → 照样超卖 → 传容器实际核数。以为参数生效了实际 -1 默认值仍走自动模式 → 显式填正整数。无视pthread_setaffinity_np failed→ 线程乱跳p95 延迟抖 → 显式钉线程数别靠自动绑核。高 intra 线程叠加开启enable_cpu_mem_arena→ 内存跟着线程数膨胀 → 限线程后顺手把 arena 关掉。【免费下载链接】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），仅供参考