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 部署進(jìn) Docker 容器后最常見的兩個性能問題是容器 CPU 占用飆到 700% 以上以及 onnxruntime 日志里出現(xiàn)pthread_setaffinity_np failed。本文按現(xiàn)象 → 原理 → 修復(fù) → 驗證把排查和修復(fù)過程走一遍?，F(xiàn)象自查pthread_setaffinity_np 日志與 CPU 796% 指標(biāo)先對號入座下面兩條證據(jù)出現(xiàn)任意一條都可以按本文繼續(xù)排查。第一條日志里冒出這樣一行W pthread_setaffinity_np failed它出現(xiàn)在 ONNX Runtime 創(chuàng)建會話階段AMD CPU 或容器環(huán)境里更常見。進(jìn)程不崩、識別結(jié)果也正常但很容易讓人心里沒底。第二條docker stats里看到類似讀數(shù)CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一個 OCR 容器吃滿 7~8 個核宿主機上的其他服務(wù)會被連帶拖慢。原因分析ONNX Runtime 親和性失敗與線程數(shù)失控CPU 親和性一句話講告訴操作系統(tǒng)這個線程只能跑在哪些核上。它的目的是減少線程在核之間遷移帶來的數(shù)據(jù)搬運開銷。為什么在容器里會失敗容器通過 cgroup/cpuset 限制了進(jìn)程可見的核ONNX Runtime 想綁定的核集合和容器實際被允許用的核集合對不上系統(tǒng)調(diào)用就返回失敗日志里那行 warning 由此而來。它是警告不是錯誤不影響識別正確性。為什么 CPU 會飆高先看項目默認(rèn)配置 config.yamlEngineConfig: onnxruntime: intra_op_num_threads: -1 inter_op_num_threads: -1-1 代表自動決定。在引擎實現(xiàn) inference_engine/onnxruntime/main.py 中自動路徑讀取os.cpu_count()而它在容器內(nèi)往往返回的是宿主機全部核數(shù)不是你的配額。打個比方容器只給你 4 核的廚房你卻按 32 核招了 32 個工人全擠進(jìn)來互相搶灶臺。更糟的是 RapidOCR 要跑 det、cls、rec 三個模型各自都會建線程池CPU% 很容易疊加到 700% 以上。修復(fù)步驟onnxruntime 線程數(shù)設(shè)置與 docker --cpus 限制第 1 步限住 onnxruntime 線程數(shù)做什么把intra_op_num_threads/inter_op_num_threads從 -1 改成固定值。怎么做構(gòu)造引擎時通過 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怎么判斷生效看進(jìn)程線程數(shù)是否顯著變少ps -T -p $(docker inspect -f {{.State.Pid}} rapidocr) | wc -l第 2 步設(shè)置容器 CPU 配額做什么用--cpus把容器 CPU 配額鎖死讓線程數(shù)和配額匹配。docker run --cpus4 --rm -it rapidocr:latest rapidocr -img doc.jpg用 compose 部署時在對應(yīng)服務(wù)里加限流配置compose v2 對非 swarm 場景已支持deploy: resources: limits: cpus: 4項目自帶的 docker/docker-compose.yaml 面向開發(fā)測試鏡像未含 CPU 限制生產(chǎn)部署需自行補上。怎么判斷生效docker stats里 CPU% 不再超過 400%4 核 × 100%。第 3 步處理親和性警告可選做完第 1 步后ONNX Runtime 不再走自動親和路徑pthread_setaffinity_np failed這行在多數(shù)場景會隨之消失。若仍有殘留它只是 warning不必當(dāng)作故障處理具體行為以 ONNX Runtime 官方文檔為準(zhǔn)。驗證方法docker stats 前后對比與線程數(shù)確認(rèn)對比docker stats --no-stream前后讀數(shù)CPU% 應(yīng)從 700% 區(qū)間降到 400% 以內(nèi)。跑一次rapidocr -img doc.jpg確認(rèn)識別結(jié)果仍正常返回。檢查輸出中的耗時字段若限線程后耗時偏高把 intra 從 4 提到 8 再測逐步找平衡點。下圖是一張只含單個單詞的測試圖適合用來快速確認(rèn)改線程數(shù)后輸出是否穩(wěn)定一句話收束先釘死線程數(shù)再鎖容器配額CPU 問題基本就解決了。避坑提示intra 和 inter 不要都設(shè)大4 核配額下建議 intra4、inter2 起步測試再按耗時微調(diào)?！久赓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)作聲明：本文部分內(nèi)容由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 部署進(jìn) Docker 容器后最常見的兩個性能問題是容器 CPU 占用飆到 700% 以上以及 onnxruntime 日志里出現(xiàn)pthread_setaffinity_np failed。本文按現(xiàn)象 → 原理 → 修復(fù) → 驗證把排查和修復(fù)過程走一遍?，F(xiàn)象自查pthread_setaffinity_np 日志與 CPU 796% 指標(biāo)先對號入座下面兩條證據(jù)出現(xiàn)任意一條都可以按本文繼續(xù)排查。第一條日志里冒出這樣一行W pthread_setaffinity_np failed它出現(xiàn)在 ONNX Runtime 創(chuàng)建會話階段AMD CPU 或容器環(huán)境里更常見。進(jìn)程不崩、識別結(jié)果也正常但很容易讓人心里沒底。第二條docker stats里看到類似讀數(shù)CONTAINER ID NAME CPU % MEM USAGE 8f3a2c1e9d40 rapidocr 796.91% 402MiB / 1.9GiB一個 OCR 容器吃滿 7~8 個核宿主機上的其他服務(wù)會被連帶拖慢。原因分析ONNX Runtime 親和性失敗與線程數(shù)失控CPU 親和性一句話講告訴操作系統(tǒng)這個線程只能跑在哪些核上。它的目的是減少線程在核之間遷移帶來的數(shù)據(jù)搬運開銷。為什么在容器里會失敗容器通過 cgroup/cpuset 限制了進(jìn)程可見的核ONNX Runtime 想綁定的核集合和容器實際被允許用的核集合對不上系統(tǒng)調(diào)用就返回失敗日志里那行 warning 由此而來。它是警告不是錯誤不影響識別正確性。為什么 CPU 會飆高先看項目默認(rèn)配置 config.yamlEngineConfig: onnxruntime: intra_op_num_threads: -1 inter_op_num_threads: -1-1 代表自動決定。在引擎實現(xiàn) inference_engine/onnxruntime/main.py 中自動路徑讀取os.cpu_count()而它在容器內(nèi)往往返回的是宿主機全部核數(shù)不是你的配額。打個比方容器只給你 4 核的廚房你卻按 32 核招了 32 個工人全擠進(jìn)來互相搶灶臺。更糟的是 RapidOCR 要跑 det、cls、rec 三個模型各自都會建線程池CPU% 很容易疊加到 700% 以上。修復(fù)步驟onnxruntime 線程數(shù)設(shè)置與 docker --cpus 限制第 1 步限住 onnxruntime 線程數(shù)做什么把intra_op_num_threads/inter_op_num_threads從 -1 改成固定值。怎么做構(gòu)造引擎時通過 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怎么判斷生效看進(jìn)程線程數(shù)是否顯著變少ps -T -p $(docker inspect -f {{.State.Pid}} rapidocr) | wc -l第 2 步設(shè)置容器 CPU 配額做什么用--cpus把容器 CPU 配額鎖死讓線程數(shù)和配額匹配。docker run --cpus4 --rm -it rapidocr:latest rapidocr -img doc.jpg用 compose 部署時在對應(yīng)服務(wù)里加限流配置compose v2 對非 swarm 場景已支持deploy: resources: limits: cpus: 4項目自帶的 docker/docker-compose.yaml 面向開發(fā)測試鏡像未含 CPU 限制生產(chǎn)部署需自行補上。怎么判斷生效docker stats里 CPU% 不再超過 400%4 核 × 100%。第 3 步處理親和性警告可選做完第 1 步后ONNX Runtime 不再走自動親和路徑pthread_setaffinity_np failed這行在多數(shù)場景會隨之消失。若仍有殘留它只是 warning不必當(dāng)作故障處理具體行為以 ONNX Runtime 官方文檔為準(zhǔn)。驗證方法docker stats 前后對比與線程數(shù)確認(rèn)對比docker stats --no-stream前后讀數(shù)CPU% 應(yīng)從 700% 區(qū)間降到 400% 以內(nèi)。跑一次rapidocr -img doc.jpg確認(rèn)識別結(jié)果仍正常返回。檢查輸出中的耗時字段若限線程后耗時偏高把 intra 從 4 提到 8 再測逐步找平衡點。下圖是一張只含單個單詞的測試圖適合用來快速確認(rèn)改線程數(shù)后輸出是否穩(wěn)定一句話收束先釘死線程數(shù)再鎖容器配額CPU 問題基本就解決了。避坑提示intra 和 inter 不要都設(shè)大4 核配額下建議 intra4、inter2 起步測試再按耗時微調(diào)?！久赓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)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考