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。本文按現象 → 原理 → 修復 → 驗證把排查和修復過程走一遍?，F象自查pthread_setaffinity_np 日志與 CPU 796% 指標先對號入座下面兩條證據出現任意一條都可以按本文繼續(xù)排查。第一條日志里冒出這樣一行W pthread_setaffinity_np failed它出現在 ONNX Runtime 創(chuàng)建會話階段AMD CPU 或容器環(huán)境里更常見。進程不崩、識別結果也正常但很容易讓人心里沒底。第二條docker stats里看到類似讀數CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一個 OCR 容器吃滿 7~8 個核宿主機上的其他服務會被連帶拖慢。原因分析ONNX Runtime 親和性失敗與線程數失控CPU 親和性一句話講告訴操作系統(tǒng)這個線程只能跑在哪些核上。它的目的是減少線程在核之間遷移帶來的數據搬運開銷。為什么在容器里會失敗容器通過 cgroup/cpuset 限制了進程可見的核ONNX Runtime 想綁定的核集合和容器實際被允許用的核集合對不上系統(tǒng)調用就返回失敗日志里那行 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 面向開發(fā)測試鏡像未含 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% 區(qū)間降到 400% 以內。跑一次rapidocr -img doc.jpg確認識別結果仍正常返回。檢查輸出中的耗時字段若限線程后耗時偏高把 intra 從 4 提到 8 再測逐步找平衡點。下圖是一張只含單個單詞的測試圖適合用來快速確認改線程數后輸出是否穩(wěn)定一句話收束先釘死線程數再鎖容器配額CPU 問題基本就解決了。避坑提示intra 和 inter 不要都設大4 核配額下建議 intra4、inter2 起步測試再按耗時微調?！久赓M下載鏈接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.項目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR創(chuàng)作聲明：本文部分內容由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。本文按現象 → 原理 → 修復 → 驗證把排查和修復過程走一遍?，F象自查pthread_setaffinity_np 日志與 CPU 796% 指標先對號入座下面兩條證據出現任意一條都可以按本文繼續(xù)排查。第一條日志里冒出這樣一行W pthread_setaffinity_np failed它出現在 ONNX Runtime 創(chuàng)建會話階段AMD CPU 或容器環(huán)境里更常見。進程不崩、識別結果也正常但很容易讓人心里沒底。第二條docker stats里看到類似讀數CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一個 OCR 容器吃滿 7~8 個核宿主機上的其他服務會被連帶拖慢。原因分析ONNX Runtime 親和性失敗與線程數失控CPU 親和性一句話講告訴操作系統(tǒng)這個線程只能跑在哪些核上。它的目的是減少線程在核之間遷移帶來的數據搬運開銷。為什么在容器里會失敗容器通過 cgroup/cpuset 限制了進程可見的核ONNX Runtime 想綁定的核集合和容器實際被允許用的核集合對不上系統(tǒng)調用就返回失敗日志里那行 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 面向開發(fā)測試鏡像未含 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% 區(qū)間降到 400% 以內。跑一次rapidocr -img doc.jpg確認識別結果仍正常返回。檢查輸出中的耗時字段若限線程后耗時偏高把 intra 從 4 提到 8 再測逐步找平衡點。下圖是一張只含單個單詞的測試圖適合用來快速確認改線程數后輸出是否穩(wěn)定一句話收束先釘死線程數再鎖容器配額CPU 問題基本就解決了。避坑提示intra 和 inter 不要都設大4 核配額下建議 intra4、inter2 起步測試再按耗時微調?！久赓M下載鏈接】RapidOCR Awesome OCR multiple programing languages toolkits based on ONNX Runtime, OpenVINO, MNN, PaddlePaddle, TensorRT and PyTorch.項目地址: https://gitcode.com/GitHub_Trending/ra/RapidOCR創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考