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