1. RK3588設(shè)備在邊緣現(xiàn)場死機(jī)的三種典型場景做邊緣AI部署做到第三個(gè)年頭我越來越確信一件事真正讓RK3588這類設(shè)備在7×24運(yùn)行中倒下的往往不是某個(gè)不可描述的軟硬件Bug而是三個(gè)看起來不起眼的工程問題。這三個(gè)問題如果沒人管設(shè)備就會在某個(gè)凌晨悄無聲息地掉線而現(xiàn)場的人只能坐兩個(gè)小時(shí)車去手動(dòng)斷電重啟。先看第一個(gè)也是最容易被低估的一個(gè)——熱崩潰。RK3588是一顆8核SoC4個(gè)Cortex-A76大核加4個(gè)Cortex-A55小核還集成了一顆6 TOPS算力的NPU。CPU和NPU同時(shí)滿載的時(shí)候整板功耗可以拉到15W甚至更高。邊緣設(shè)備的外殼多半是金屬密封或者半密封的裝在室外配電柜、路側(cè)機(jī)箱、車頂盒子里夏天的環(huán)境溫度能到45℃以上。散熱設(shè)計(jì)稍微不到位SoC結(jié)溫就會頂?shù)?5℃、90℃這時(shí)候內(nèi)核的 thermal 框架開始限頻CPU從2.4GHz一路降到1.2GHz。降頻之后推理幀率斷崖式下跌業(yè)務(wù)側(cè)任務(wù)開始堆積負(fù)載反而更高溫度繼續(xù)往上頂最終觸發(fā)硬件熱保護(hù)直接斷電。整個(gè)過程像多米諾骨牌第一步往往是風(fēng)扇策略不給力最后一步則是完全掉電。第二個(gè)場景是資源漸進(jìn)式泄漏。做過RK3588上YOLOv8部署的同學(xué)應(yīng)該有體會一個(gè)C推理服務(wù)如果圖像緩沖、tensor、epoll句柄這些資源有任何一環(huán)沒有釋放干凈跑三到五天內(nèi)存就會悄悄漲出一兩百M(fèi)B。視頻類業(yè)務(wù)更明顯RTSP拉流、硬解碼、推理、結(jié)果上報(bào)這個(gè)鏈路如果沒做超時(shí)保護(hù)網(wǎng)絡(luò)一抖動(dòng)就會卡在某個(gè)阻塞調(diào)用里然后句柄越積越多。再有就是日志。系統(tǒng)日志和應(yīng)用日志如果不控制體積/var/log滿了之后很多服務(wù)會因?yàn)閷懖涣巳罩径苯恿T工表現(xiàn)就是設(shè)備假死。這類問題因?yàn)椴皇撬查g發(fā)生的所以最惡心往往在交付驗(yàn)收完之后的第三周才冒出來。第三個(gè)場景是單點(diǎn)故障無法自愈。應(yīng)用進(jìn)程崩了沒人拉起業(yè)務(wù)就斷了內(nèi)核panic了但系統(tǒng)沒有配置自動(dòng)重啟機(jī)器就一直卡死在串口輸出畫面某個(gè)線程死鎖導(dǎo)致整個(gè)系統(tǒng)響應(yīng)不了但沒有外部看門狗把系統(tǒng)打斷。說白了很多設(shè)備的死機(jī)本質(zhì)上只是壞了沒人管。我在項(xiàng)目交付中見過太多現(xiàn)場設(shè)備Console口插上屏幕上一堆調(diào)用棧系統(tǒng)是徹底涼了的但沒有任何機(jī)制能讓它自己爬起來。這三個(gè)場景擺在一起結(jié)論其實(shí)很清晰想讓RK3588邊緣AI設(shè)備做到7×24不死機(jī)不能只靠某個(gè)單一的看門狗或者某個(gè)優(yōu)秀的電控設(shè)計(jì)而是需要一套從底層硬件到業(yè)務(wù)進(jìn)程的完整守護(hù)機(jī)制。我習(xí)慣把這套機(jī)制稱作 Guardian——它不是一個(gè)開源軟件也不是某個(gè)商業(yè)產(chǎn)品的名字而是我在多個(gè)RK3588邊緣智能項(xiàng)目里沉淀下來的一套工程方法論包含散熱閉環(huán)、內(nèi)核參數(shù)、看門狗聯(lián)動(dòng)、進(jìn)程守護(hù)、存儲保護(hù)等一整套能落地、能復(fù)制、能驗(yàn)證的實(shí)踐。2. Guardian守護(hù)體系的整體設(shè)計(jì)三層防線怎么分工Guardian這套體系的思路可以用一句工程上行話概括不要假設(shè)系統(tǒng)不會掛要設(shè)計(jì)系統(tǒng)掛了之后能自己爬起來。業(yè)界做高可用設(shè)備原則是相同的快速失敗、自動(dòng)恢復(fù)。邊緣AI設(shè)備和數(shù)據(jù)中心服務(wù)器最大的區(qū)別在于它沒有人值守?cái)嗔司W(wǎng)也沒有運(yùn)維人員能第一時(shí)間介入所以一切恢復(fù)動(dòng)作都必須是自動(dòng)的、本地的、不依賴外部網(wǎng)絡(luò)的。按照這個(gè)原則我把守護(hù)體系分成三層。第一層是硬件級防線。內(nèi)核panic、軟鎖死、硬鎖死、任務(wù)卡死這些情況操作系統(tǒng)自身已經(jīng)失去了正?；謴?fù)的能力必須依靠看門狗在毫秒到秒級的時(shí)間內(nèi)把整個(gè)SoC復(fù)位掉。RK3588內(nèi)部有WDT外設(shè)板級dts里一般默認(rèn)使能Linux內(nèi)核的watchdog驅(qū)動(dòng)也會把它注冊成/dev/watchdog節(jié)點(diǎn)。這一層要做的核心事情是配置好內(nèi)核出問題就panic、panic之后就重啟的策略并在用戶空間安排一個(gè)喂狗進(jìn)程讓看門狗既能監(jiān)視系統(tǒng)是否卡死又不會誤觸發(fā)復(fù)位。第二層是系統(tǒng)軟件層。它負(fù)責(zé)處理那些硬件看門狗管不了的問題——比如內(nèi)存泄漏、文件系統(tǒng)寫滿、日志無限增長、某些服務(wù)假死。這一層的工具主要是systemd、cgroup、logrotate、overlayfs以及一組精心調(diào)過的內(nèi)核sysctl參數(shù)。打個(gè)比方硬件看門狗是整機(jī)心臟驟停時(shí)的電擊器系統(tǒng)軟件層的職責(zé)則更像日常體檢在病情惡化之前就把它攔下來。第三層是業(yè)務(wù)應(yīng)用層。AI推理進(jìn)程、RTSP拉流進(jìn)程、外設(shè)通信進(jìn)程這些才是設(shè)備存在的意義。這一層要解決的是某個(gè)業(yè)務(wù)進(jìn)程掛了但系統(tǒng)其他部分還活著的情況核心手段是健康檢查加自動(dòng)重啟。進(jìn)程不是拉起一次就完了而是要形成一個(gè)閉環(huán)定期檢查心跳心跳異常就殺掉重啟重啟次數(shù)過多就告警并降級運(yùn)行。這三層防線缺一不可。只做硬件看門狗設(shè)備的業(yè)務(wù)邏輯爛成一鍋粥也沒人管只做進(jìn)程守護(hù)內(nèi)核一旦panic就只能等人工到場只做監(jiān)控和參數(shù)調(diào)優(yōu)而不做硬件兜底整個(gè)系統(tǒng)還是裸奔。我自己踩過不少坑之后才總結(jié)出這個(gè)三層架構(gòu)后面幾章我會把每一層的具體做法和參數(shù)細(xì)節(jié)都講清楚照著做同類設(shè)備至少不會再因?yàn)榛A(chǔ)功課沒做而掉線。這里還要特別強(qiáng)調(diào)一個(gè)設(shè)計(jì)原則守護(hù)進(jìn)程本身也必須被守護(hù)。溫控腳本、喂狗進(jìn)程、健康檢查服務(wù)如果它們自己崩了就失去意義了。所以這些腳本和進(jìn)程都應(yīng)該注冊成systemd服務(wù)并納入WatchdogSec的監(jiān)督范圍。這一條看著簡單實(shí)操中很多人會忽略結(jié)果就是守護(hù)機(jī)制成了紙糊的盾牌平時(shí)看著在跑關(guān)鍵時(shí)刻它先躺下了。3. 散熱閉環(huán)控制溫度、風(fēng)扇轉(zhuǎn)速與PWM調(diào)參的完整鏈路散熱是RK3588邊緣設(shè)備7×24穩(wěn)定性的命門尤其那些主動(dòng)風(fēng)冷方案的板卡。我見過太多設(shè)備死機(jī)是因?yàn)轱L(fēng)扇策略寫得太粗糙——要么溫度到了80℃才開始轉(zhuǎn)要么風(fēng)扇永遠(yuǎn)低速轉(zhuǎn)導(dǎo)致積灰卡死。這一章我把散熱閉環(huán)需要做的事拆開講每一步都有實(shí)測依據(jù)。3.1 找到正確的溫度數(shù)據(jù)源做溫控的第一步是找到CPU/SoC溫度到底在哪個(gè)sysfs節(jié)點(diǎn)。Rockchip平臺在標(biāo)準(zhǔn)內(nèi)核thermal框架下會注冊多個(gè)thermal zone每個(gè)zone有type和temp兩個(gè)重要屬性。我用的排查命令是for z in /sys/class/thermal/thermal_zone*/; do echo -n $z type; cat $z/type echo -n temp; cat $z/temp done實(shí)測RK3588的Debian 11系統(tǒng)上soc_thermal通常對應(yīng)thermal_zone0讀取出來的temp單位是毫攝氏度比如85000代表85℃。某些板卡會在hwmon節(jié)點(diǎn)上也暴露溫度比如/sys/class/hwmon/hwmon1/temp1_input兩者數(shù)值應(yīng)該一致但以thermal zone為準(zhǔn)最靠譜因?yàn)閮?nèi)核調(diào)頻調(diào)壓用的就是thermal框架的數(shù)據(jù)。需要留意的是RK3588內(nèi)部不止一顆溫度傳感器CPU、GPU、NPU各有各的傳感器節(jié)點(diǎn)。如果只盯著CPU溫度做風(fēng)扇控制NPU跑推理時(shí)溫度可能已經(jīng)爆了而風(fēng)扇還在低速轉(zhuǎn)。穩(wěn)妥做法是讀完所有zone取最大值作為溫控依據(jù)。我一般寫一個(gè)get_temp()函數(shù)遍歷所有zone取最大值超時(shí)重試三次保證讀取鏈路本身可靠。3.2 風(fēng)扇轉(zhuǎn)速讀取PWM Capture與FG脈沖換算rk3588 讀取風(fēng)扇轉(zhuǎn)速這個(gè)訴求很多開發(fā)板玩家都在問。風(fēng)扇轉(zhuǎn)速信號來自風(fēng)扇內(nèi)部的FG引腳Frequence Generator它每轉(zhuǎn)一圈會輸出若干個(gè)脈沖。RK3588本身沒有專用的RPM計(jì)數(shù)器但它的PWM外設(shè)支持capture模式正好可以測量FG引腳上的脈沖頻率再換算成轉(zhuǎn)速這就是很多人提到的rk3588 pwm capture用法。先看板級dts里PWM capture通道怎么配pwm_capture: pwm-capture { compatible rockchip,rk3588-pwm-capture; pwm-names fan-tach; pwms pwm2 0 1000000 0; status okay; };實(shí)際引腳和通道以板卡原理圖為準(zhǔn)不同開發(fā)板差別很大。配置好后用戶在/sys/class/pwm/pwmchipN/下面export對應(yīng)通道讀取capture文件echo 0 /sys/class/pwm/pwmchip2/export cat /sys/class/pwm/pwmchip2/pwm0/capture輸出類似period8333333 duty_cycle4166666period是脈沖周期納秒。頻率等于1秒除以周期然后乘上換算系數(shù)得到轉(zhuǎn)速。常規(guī)三線PWM風(fēng)扇FG信號每轉(zhuǎn)輸出2個(gè)脈沖所以RPM (1 / period_seconds) × 60 / 2舉個(gè)例子如果讀到period8333333ns也就是頻率120HzRPM 120 × 60 / 2 3600。不過不同廠家風(fēng)扇的FG脈沖數(shù)可能不一樣有的是每轉(zhuǎn)4脈沖我建議拿到風(fēng)扇先實(shí)測標(biāo)定一次——把風(fēng)扇額定轉(zhuǎn)速和頻率對應(yīng)起來確定好系數(shù)再寫進(jìn)代碼。3.3 溫控策略與PWM曲線設(shè)計(jì)PWM風(fēng)扇調(diào)速有兩種常見實(shí)現(xiàn)方式。一種是走內(nèi)核thermal框架在dts里配pwm-fan節(jié)點(diǎn)和cooling-map讓內(nèi)核根據(jù)溫度自動(dòng)調(diào)風(fēng)扇fan: pwm-fan { compatible pwm-fan; #cooling-cells 2; pwms pwm1 0 40000 0; cooling-levels 0 64 128 192 255; status okay; };這種方式省心內(nèi)核自動(dòng)處理thermal throttling和風(fēng)扇聯(lián)動(dòng)的邏輯。但缺點(diǎn)是調(diào)參不直觀而且不好加風(fēng)扇卡死檢測的邏輯。我實(shí)際項(xiàng)目里更多是用用戶空間的守護(hù)腳本來直接控制PWM#!/bin/bash # guardian-fan.sh - 溫度采集 風(fēng)扇轉(zhuǎn)速讀取 PWM 控制 FAN_PWM/sys/class/pwm/pwmchip1/pwm0 TEMP_ZONES/sys/class/thermal CAPTURE/sys/class/pwm/pwmchip2/pwm0 get_temp() { local max0 for z in $TEMP_ZONES/thermal_zone*/; do local t$(cat $z/temp 2/dev/null || echo 0) [ $t -gt $max ] max$t done echo $max } get_rpm() { local cap$(cat $CAPTURE/capture 2/dev/null) local period$(echo $cap | sed -n s/period\([0-9]*\).*/\1/p) [ -z $period ] { echo 0; return; } echo $(( 1000000000 / period * 60 / 2 / 1000 )) } while true; do temp$(get_temp) # 毫攝氏度 temp_deg$((temp / 1000)) rpm$(get_rpm) duty0 if [ $temp_deg -ge 70 ]; then duty255 elif [ $temp_deg -ge 45 ]; then # 45~70度線性映射 duty$(( (temp_deg - 45) * 255 / 25 )) fi echo $duty $FAN_PWM/duty_cycle # 日志記錄方便事后分析 logger -t guardian temp${temp_deg}C rpm${rpm} duty${duty} sleep 2 done我推薦的分段線性溫控策略45℃以下風(fēng)扇低速或停轉(zhuǎn)45到70℃按線性比例加速70℃以上直接全速。這個(gè)策略比溫度高了就全速、溫度低了就停轉(zhuǎn)的死板模式更平順能避免風(fēng)扇頻繁啟停帶來的噪聲和磨損。如果對噪聲敏感可以把風(fēng)扇啟動(dòng)閾值調(diào)到50℃但上限一定要留夠余量——我一般在75℃就強(qiáng)制全速不給熱量累積的機(jī)會。3.4 風(fēng)扇異常降級保護(hù)溫控邏輯跑通之后最容易被忽略的是風(fēng)扇故障檢測。風(fēng)扇屬于機(jī)電產(chǎn)品有壽命會卡灰會缺油會斷線。不要等到SoC熱保護(hù)關(guān)機(jī)了才反應(yīng)過來。在上面的腳本基礎(chǔ)上我加了一段異常邏輯當(dāng)PWM占空比已經(jīng)超過一定閾值但讀取到的轉(zhuǎn)速低于200RPM且持續(xù)30秒就判定風(fēng)扇故障強(qiáng)制PWM全速輸出同時(shí)把故障狀態(tài)寫到監(jiān)控?cái)?shù)據(jù)庫并觸發(fā)本地告警。轉(zhuǎn)速為0還有一種可能就是capture通道本身配置錯(cuò)了。所以我在項(xiàng)目里特意做了PWM開度與轉(zhuǎn)速聯(lián)動(dòng)檢查風(fēng)扇開度從0調(diào)到255如果在設(shè)定時(shí)間內(nèi)轉(zhuǎn)速沒有按預(yù)期上升就認(rèn)為測速鏈路有問題同樣要告警。這個(gè)檢查在設(shè)備剛啟動(dòng)的時(shí)候跑一次就夠了不用總是做。風(fēng)扇異常時(shí)最怕的是業(yè)務(wù)還在繼續(xù)跑熱量還在繼續(xù)累積。所以降級方案不只是全速轉(zhuǎn)風(fēng)扇還要考慮主動(dòng)降載檢測到風(fēng)扇故障后詢問業(yè)務(wù)管理系統(tǒng)是否可以降低AI推理頻率或關(guān)閉一路視頻分析優(yōu)先保系統(tǒng)和最核心的業(yè)務(wù)。這個(gè)策略因項(xiàng)目而異但思路是通用的——散熱異常時(shí)先限制發(fā)熱源再等待運(yùn)維介入。4. 系統(tǒng)級不死保障內(nèi)核參數(shù)、硬件看門狗與systemd聯(lián)動(dòng)散熱保證的是硬件不死系統(tǒng)級保障要解決的是操作系統(tǒng)本身假死和真死的問題。很多RK3588設(shè)備跑著跑著SSH連不上串口也沒反應(yīng)但電源燈還亮著這種狀態(tài)最讓人頭疼。Guardian在這層的目標(biāo)是能恢復(fù)的自動(dòng)恢復(fù)不能恢復(fù)的快速復(fù)位盡量縮短設(shè)備不可用的時(shí)間窗口。4.1 內(nèi)核關(guān)鍵參數(shù)與觸發(fā)條件在Debian 11或Ubuntu系統(tǒng)上我建議在/etc/sysctl.d/99-guardian.conf里寫入以下參數(shù)kernel.panic 5 kernel.panic_on_oops 1 kernel.softlockup_panic 1 kernel.hardlockup_panic 1 kernel.hung_task_timeout_secs 60 kernel.hung_task_panic 1 kernel.nmi_watchdog 1 fs.file-max 65536 fs.inotify.max_user_watches 262144逐個(gè)說下我為什么這么設(shè)。kernel.panic5是內(nèi)核panic后延遲5秒自動(dòng)重啟。延遲是為了讓panic信息有時(shí)間刷到console方便排查。如果設(shè)為0系統(tǒng)卡在panic界面等人工到場就失去了自愈能力。kernel.panic_on_oops1讓內(nèi)核在處理Oops非致命的內(nèi)核錯(cuò)誤時(shí)升級為panic從而觸發(fā)重啟。為什么要這么做因?yàn)镺ops說明內(nèi)核已經(jīng)處于不可靠狀態(tài)繼續(xù)跑下去可能產(chǎn)生更嚴(yán)重的損壞不如直接重啟。kernel.softlockup_panic1和kernel.hardlockup_panic1讓CPU軟鎖死和硬鎖死也能觸發(fā)panic。軟鎖死通常是中斷上下文里死循環(huán)硬鎖死可能和硬件異常有關(guān)。這兩個(gè)參數(shù)在內(nèi)核里默認(rèn)可能是0不加的話CPU鎖死就永遠(yuǎn)鎖死了。kernel.hung_task_timeout_secs60和kernel.hung_task_panic1用于檢測用戶空間任務(wù)長時(shí)間處于D狀態(tài)不可中斷睡眠。D狀態(tài)任務(wù)卡住直接影響業(yè)務(wù)同時(shí)很可能是IO子系統(tǒng)出了問題的信號。設(shè)成60秒超過就panic重啟。這個(gè)時(shí)間不能太短否則在高負(fù)載IO場景會誤觸發(fā)我試過30秒在日志量大的設(shè)備上出現(xiàn)過誤報(bào)調(diào)到60秒就穩(wěn)定了。這些參數(shù)在邊緣AI設(shè)備的套路基本是固定的。大家在做rk3588系統(tǒng)定制的時(shí)候拿這套配置基本不會出大問題。4.2 硬件看門狗的接入與喂狗策略RK3588的dts里如果有watchdog節(jié)點(diǎn)Linux內(nèi)核會注冊出/dev/watchdog。我一般先看一眼節(jié)點(diǎn)是否存在ls -l /dev/watchdog* cat /dev/watchdog 21 | head -1喂狗的方式很簡單往設(shè)備寫任意數(shù)據(jù)就會觸發(fā)一次喂狗操作。系統(tǒng)里常見的喂狗工具是wd_keepalive也可以自己寫個(gè)循環(huán)腳本#!/bin/bash while true; do echo -n K /dev/watchdog sleep 5 done關(guān)鍵在喂狗間隔和WDT超時(shí)時(shí)間的匹配。如果看門狗超時(shí)是30秒喂狗周期建議控制在5到10秒也就是超時(shí)時(shí)間的六分之一到三分之一。喂太頻繁系統(tǒng)卡死幾秒就喂不上狗看門狗也能容忍但一卡就超過30秒才能復(fù)位業(yè)務(wù)中斷時(shí)間太長。喂太慢稍微調(diào)度抖動(dòng)就會誤復(fù)位。我在實(shí)際項(xiàng)目中習(xí)慣設(shè)WDT超時(shí)30秒喂狗周期5秒留足余量。如果板子上沒有內(nèi)置WDT或者對可靠性格外敏感可以考慮外接獨(dú)立看門狗芯片比如STWD100通過GPIO做喂狗。外置看門狗的好處是即使SoC內(nèi)部時(shí)鐘或總線出了問題它依然能可靠復(fù)位。普通項(xiàng)目用RK3588內(nèi)置WDT就夠但如果設(shè)備部署在無人區(qū)我建議上外置方案多出來的成本比起一次人工出差的差旅費(fèi)劃算得多。4.3 systemd WatchdogSec業(yè)務(wù)級心跳與硬件復(fù)位聯(lián)動(dòng)系統(tǒng)啟動(dòng)后systemd作為第一個(gè)用戶空間進(jìn)程它的健康狀態(tài)也應(yīng)該被監(jiān)督。在/etc/systemd/system.conf里有一個(gè)關(guān)鍵參數(shù)RuntimeWatchdogSec30設(shè)置這個(gè)參數(shù)后systemd主進(jìn)程會周期性地喂養(yǎng)內(nèi)核的/dev/watchdog。這樣即使systemd它自己卡死了硬件看門狗也能在30秒內(nèi)復(fù)位整個(gè)系統(tǒng)。配合前面的kernel.panic5一條完整的復(fù)位鏈就通了業(yè)務(wù)進(jìn)程卡死 → systemd殺掉重啟系統(tǒng)內(nèi)核卡死 → 內(nèi)核panic → 自動(dòng)重啟systemd卡死 → 硬件看門狗復(fù)位。在具體服務(wù)單元里還可以給關(guān)鍵業(yè)務(wù)進(jìn)程單獨(dú)配WatchdogSec[Service] ExecStart/usr/bin/guardian-ai --config /etc/guardian/ai.conf Restartalways RestartSec3 WatchdogSec30 MemoryMax2G MemoryHigh1500M TasksMax256配合WatchdogSec應(yīng)用進(jìn)程需要定期調(diào)用sd_notify(0, WATCHDOG1)通知systemd自己還活著。C代碼里是這樣的#include systemd/sd-daemon.h while (1) { /* 業(yè)務(wù)邏輯 */ run_inference(); sd_notify(0, WATCHDOG1); sleep(5); }一個(gè)容易犯的錯(cuò)誤是把喂狗放在獨(dú)立線程里這樣主業(yè)務(wù)線程卡死時(shí)systemd仍然能收到心跳看門狗根本發(fā)現(xiàn)不了問題。我要求喂狗必須和業(yè)務(wù)心跳綁在同一個(gè)執(zhí)行路徑上——每次跑完核心推理循環(huán)就喂一次這樣systemd心跳實(shí)際上代表的是業(yè)務(wù)側(cè)的健康狀態(tài)而不是某個(gè)空轉(zhuǎn)線程的狀態(tài)。4.4 應(yīng)急恢復(fù)兜底recovery和雙系統(tǒng)方案軟件再強(qiáng)也總有把自己搞壞的一天比如誤刷了錯(cuò)誤的固件。所以Guardian的最底層兜底是硬件恢復(fù)通路。瑞芯微平臺的recovery機(jī)制大家應(yīng)該都熟按住recovery/maskrom鍵用USB Type-C數(shù)據(jù)線連到電腦上電然后工具就能識別到設(shè)備進(jìn)入升級模式。這套機(jī)制建議在項(xiàng)目交付文檔里寫清楚現(xiàn)場維護(hù)的人必須掌握。比recovery更進(jìn)一步的是A/B雙系統(tǒng)分區(qū)。系統(tǒng)A啟動(dòng)失敗時(shí)引導(dǎo)程序自動(dòng)切到系統(tǒng)B系統(tǒng)B再失敗就從recovery引導(dǎo)。這個(gè)方案需要存儲空間翻倍但對7×24設(shè)備來說值得考慮。我做一個(gè)戶外采集項(xiàng)目時(shí)跑過這套方案升級固件再也不用擔(dān)心寫一半斷電變磚穩(wěn)定性提升非常明顯。5. AI推理場景的進(jìn)程守護(hù)OOM隔離、心跳上報(bào)與自動(dòng)重啟前兩章保證了系統(tǒng)和硬件層面不會死透但7×24場景里最頻繁出問題的其實(shí)是AI推理和視頻流這些業(yè)務(wù)進(jìn)程。RK3588上部署YOLOv8這類模型推理進(jìn)程一般是用C寫的常駐服務(wù)一次模型加載就要幾秒鐘模型文件轉(zhuǎn)成RKNN格式后跑在NPU上。這類服務(wù)一旦掛掉設(shè)備看起來還開著機(jī)但業(yè)務(wù)已經(jīng)完全停了。5.1 用cgroup做內(nèi)存隔離AI推理服務(wù)是內(nèi)存消耗大戶模型權(quán)重、中間張量、圖像緩沖疊在一起輕松吃掉1~2GB內(nèi)存。如果系統(tǒng)內(nèi)存被某個(gè)業(yè)務(wù)進(jìn)程吃滿內(nèi)核OOM killer可能把SSH服務(wù)或者其他核心進(jìn)程殺掉設(shè)備直接失聯(lián)。解決辦法是用systemd的MemoryMax參數(shù)給每個(gè)服務(wù)設(shè)置內(nèi)存上限。[Service] MemoryMax2G MemoryHigh1500M OOMScoreAdjust500MemoryHigh是軟限制超過之后內(nèi)核會回收這個(gè)進(jìn)程的可回收內(nèi)存MemoryMax是硬限制一旦超過內(nèi)核就對這個(gè)cgroup觸發(fā)OOM。配合OOMScoreAdjust500讓OOM killer優(yōu)先殺這個(gè)業(yè)務(wù)進(jìn)程而不是殺掉systemd或sshd。這樣內(nèi)存異常時(shí)犧牲的只是一個(gè)可以自動(dòng)重啟的推理進(jìn)程整個(gè)設(shè)備仍然可訪問、可運(yùn)維。要驗(yàn)證上限是否生效可以手動(dòng)往進(jìn)程里注入一段不斷申請內(nèi)存的測試代碼觀察dmesg里OOM kill的記錄。這一步必須做不然上線后內(nèi)存泄漏爆發(fā)時(shí)系統(tǒng)可能直接卡死。5.2 AI推理進(jìn)程的心跳與自動(dòng)重啟進(jìn)程守護(hù)需要業(yè)務(wù)級心跳不是簡單的進(jìn)程存活。比如推理服務(wù)進(jìn)程還活著但內(nèi)部某個(gè)線程死鎖了外表看著一切正常實(shí)際已經(jīng)停止處理新任務(wù)。我的做法是讓服務(wù)暴露一個(gè)本地HTTP健康檢查接口比如/healthz返回最近一次推理處理的幀數(shù)和耗時(shí)。守護(hù)腳本定期請求這個(gè)接口同時(shí)驗(yàn)證兩個(gè)條件一是有響應(yīng)二是最近一次推理耗時(shí)沒有超過正常值的3倍。#!/bin/bash # guardian-health-check.sh curl --max-time 5 -s http://127.0.0.1:8090/healthz || { logger -t guardian health check failed, restarting service systemctl restart guardian-ai }把這個(gè)健康檢查腳本放到systemd timer里每30秒跑一次或者直接用systemd服務(wù)自帶的WatchdogSec機(jī)制來實(shí)現(xiàn)效果類似。關(guān)鍵點(diǎn)在于心跳要和業(yè)務(wù)卡死聯(lián)動(dòng)而不是空轉(zhuǎn)。比如推理服務(wù)內(nèi)部單獨(dú)開了個(gè)線程每5秒調(diào)用sd_notify主線程卻堵在某個(gè)圖像處理函數(shù)里出不來這種心跳就沒有意義。我一般把心跳調(diào)用放在主推理循環(huán)的每個(gè)幀處理之后而不是放在獨(dú)立線程里這樣只要心跳還在跳動(dòng)就說明核心業(yè)務(wù)還在跑。5.3 視頻流與模型加載的穩(wěn)定性細(xì)節(jié)RK3588邊緣AI設(shè)備大量用于視頻監(jiān)控場景RTSP拉流 硬解碼 推理 結(jié)果上報(bào)是標(biāo)準(zhǔn)鏈路。這個(gè)鏈路里最容易被忽視的是網(wǎng)絡(luò)抖動(dòng)。RTSP拉流線程如果阻塞在socket讀取上一旦上游攝像頭斷流這個(gè)線程可能一直卡著不返回。處理辦法是給所有socket調(diào)用加超時(shí)同時(shí)在守護(hù)腳本里加新幀看門狗實(shí)時(shí)視頻流如果超過N秒沒有新幀到達(dá)判定拉流異常重啟整個(gè)視頻處理進(jìn)程。模型加載方面RKNN推理服務(wù)啟動(dòng)時(shí)要把模型加載到NPU這個(gè)過程在冷啟動(dòng)時(shí)可能需要幾秒鐘到十幾秒。systemd服務(wù)默認(rèn)的啟動(dòng)超時(shí)是90秒正常情況下足夠用。但要注意一個(gè)問題如果系統(tǒng)剛啟動(dòng)時(shí)NPU驅(qū)動(dòng)還沒初始化完成推理服務(wù)啟動(dòng)就會失敗。我在服務(wù)單元里加了Afterrockchip-npu.service和Restartalways保證NPU就緒后再啟動(dòng)推理服務(wù)啟動(dòng)失敗也能自動(dòng)重試。內(nèi)存泄漏是AI服務(wù)的另一大隱患。我建議對每個(gè)推理服務(wù)做一次72小時(shí)的壓測每隔1小時(shí)記錄一次RSS內(nèi)存如果RSS單調(diào)上漲超過10%基本可以斷定有泄漏上線前就要修。實(shí)在趕到項(xiàng)目交付節(jié)點(diǎn)來不及修也可以用systemd的MemoryMax做一個(gè)定時(shí)重啟的折中方案——比如每天凌晨業(yè)務(wù)空閑時(shí)自動(dòng)重啟一次推理服務(wù)把所有泄漏的內(nèi)存吐回去。這個(gè)方案治標(biāo)不治本但確實(shí)能讓設(shè)備先跑起來。6. 存儲與日志的可靠性eMMC壽命、只讀根文件系統(tǒng)與日志輪轉(zhuǎn)邊緣AI設(shè)備絕大多數(shù)用eMMC做存儲。eMMC雖然比SD卡可靠得多但也不是無限寫壽命的。而且系統(tǒng)日志、AI推理日志、視頻片段如果隨意落盤要么把存儲寫穿要么把分區(qū)寫滿兩者都會導(dǎo)致設(shè)備無法正常工作。這一章講存儲和日志的守護(hù)手段。6.1 根文件系統(tǒng)只讀化把根文件系統(tǒng)設(shè)成只讀是嵌入式設(shè)備提高可靠性的經(jīng)典做法。好處顯而易見意外斷電不會破壞系統(tǒng)盤日志寫滿也不會影響系統(tǒng)目錄惡意或異常寫入更不會污染二進(jìn)制文件。在Rockchip平臺的Debian/Ubuntu上通常做法是用overlayfs把根文件系統(tǒng)合并成只讀底層內(nèi)存上層。具體實(shí)現(xiàn)可以用Linux內(nèi)核boot參數(shù)配合initramfs腳本或者安裝overlayroot后配置overlayroottmpfs配置之后重啟根文件系統(tǒng)就是tmpfs疊加在只讀的eMMC分區(qū)上了系統(tǒng)運(yùn)行時(shí)對/目錄的寫入都落在內(nèi)存重啟后自動(dòng)恢復(fù)到出廠狀態(tài)。業(yè)務(wù)數(shù)據(jù)和日志則寫入單獨(dú)的可寫分區(qū)比如/data和/var/log。這樣既保留了系統(tǒng)的靈活性又把系統(tǒng)盤寫損壞的概率降到了最低。需要注意只讀根文件系統(tǒng)會讓某些需要寫/var的包安裝失敗需要提前規(guī)劃好哪些路徑走tmpfs、哪些路徑走獨(dú)立可寫分區(qū)。我通常的做法是/etc里需要?jiǎng)討B(tài)修改的文件用bind mount映射到/data分區(qū)/var/log直接掛到/data/log/tmp和/run本來就是tmpfs不用管。6.2 日志輪轉(zhuǎn)與落盤策略日志寫滿分區(qū)是邊緣設(shè)備最常見的一種慢死。AI推理服務(wù)如果每個(gè)檢測幀都打一條日志一天能寫好幾個(gè)GBeMMC很快扛不住。我的標(biāo)準(zhǔn)策略是應(yīng)用日志統(tǒng)一寫到/data/logs配合logrotate做輪轉(zhuǎn)和壓縮。以/etc/logrotate.d/guardian-ai為例/data/logs/ai_service.log { daily rotate 7 compress delaycompress maxsize 50M missingok notifempty copytruncate }copytruncate這個(gè)選項(xiàng)很重要它確保日志文件還在被進(jìn)程打開寫入時(shí)也能安全輪轉(zhuǎn)。系統(tǒng)日志方面journald默認(rèn)會把所有日志寫到/var/log/journal如果根文件系統(tǒng)只讀化了就要把日志轉(zhuǎn)發(fā)到內(nèi)存或者只保留systemd內(nèi)存日志必要時(shí)再手動(dòng)導(dǎo)出。我一般設(shè)置SystemMaxUse200M MaxRetentionSec3dayjournald自己控制體積日志太多時(shí)自動(dòng)丟棄老日志不會把磁盤撐爆。6.3 eMMC磨損保護(hù)除了控制寫入量eMMC本身也要做一些保養(yǎng)。最關(guān)鍵的是定期執(zhí)行TRIM讓eMMC內(nèi)部GC有合理的時(shí)機(jī)整理廢棄塊fstrim -v /data可以放到cron或systemd timer里每周執(zhí)行一次。另外盡量避免在業(yè)務(wù)代碼里做高頻率小文件寫入比如每秒鐘寫一個(gè)狀態(tài)文件。日志先寫入內(nèi)存緩沖攢夠一定量再批量落盤這樣既能減少寫放大又能避免每次斷電都丟關(guān)鍵日志。如果對存儲可靠性要求更高可以啟用eMMC的硬件寫保護(hù)通過MMC工具設(shè)置永久寫保護(hù)區(qū)域或者干脆把系統(tǒng)盤做成只讀eMMC業(yè)務(wù)數(shù)據(jù)全部走外部USB SSD或者網(wǎng)絡(luò)存儲。不同方案的取舍取決于項(xiàng)目預(yù)算和數(shù)據(jù)重要性但思路都是一樣的保護(hù)存儲就是保護(hù)系統(tǒng)本身的生存能力。7. 一次完整排查實(shí)錄散熱失控導(dǎo)致的風(fēng)扇卡滯與系統(tǒng)關(guān)機(jī)前面幾章講的是理論和方法這一章我拿一個(gè)實(shí)際案例把整個(gè)排查鏈路走一遍。這個(gè)案例來自一個(gè)室外配電柜里的RK3588邊緣AI盒子跑的正是YOLOv8人員識別加RTSP視頻流設(shè)備已經(jīng)穩(wěn)定運(yùn)行了兩周突然在一個(gè)高溫午后自動(dòng)關(guān)機(jī)。7.1 現(xiàn)象與最初的懷疑方向用戶反饋設(shè)備掉線Console口接上沒有輸出ping不通電源指示燈不亮。第一反應(yīng)是斷電了后來確認(rèn)供電正常。懷疑軟件死鎖但設(shè)備是完全斷電狀態(tài)不是假死。把設(shè)備取回實(shí)驗(yàn)室上電串口看日志發(fā)現(xiàn)最后幾行是thermal zone的臨界溫度告警然后就是硬件熱保護(hù)斷電。所以問題不是軟件是設(shè)備燒過了。我把設(shè)備裝上溫度探頭重新跑壓測同時(shí)讓日志系統(tǒng)記錄溫度、風(fēng)扇PWM、轉(zhuǎn)速三個(gè)數(shù)據(jù)。到這里第一個(gè)教訓(xùn)就出現(xiàn)了如果沒有提前做監(jiān)控和日志這種故障排查會像無頭蒼蠅一樣毫無頭緒。所以我在所有RK3588項(xiàng)目里都強(qiáng)制要求記錄溫度軌跡和風(fēng)扇轉(zhuǎn)速就是為了這種時(shí)候能回放現(xiàn)場。7.2 逐層排查風(fēng)扇轉(zhuǎn)速異常的過程模擬現(xiàn)場高負(fù)載跑了大概兩天數(shù)據(jù)庫里的記錄顯示關(guān)機(jī)前幾分鐘溫度從75℃一路漲到95℃而PWM duty已經(jīng)是255全速。按理說全速運(yùn)轉(zhuǎn)下溫度不應(yīng)該升這么快唯一的解釋是風(fēng)扇沒有在轉(zhuǎn)。我調(diào)出轉(zhuǎn)速記錄果然PWM全速之前的幾十分鐘轉(zhuǎn)速已經(jīng)從3000RPM快速下降到幾百RPM最后穩(wěn)定在0附近。風(fēng)扇故障幾乎可以確定了。但為什么會突然轉(zhuǎn)速下降打開盒子檢查發(fā)現(xiàn)風(fēng)扇葉片上積了一層灰軸承發(fā)澀用手撥動(dòng)葉片有明顯阻力。長期運(yùn)行加灰塵卡滯導(dǎo)致風(fēng)扇軸心阻力變大最終停轉(zhuǎn)。為了確認(rèn)測速鏈路沒問題而不是誤報(bào)我用示波器直接測風(fēng)扇FG引腳葉片停轉(zhuǎn)后確實(shí)沒有任何脈沖輸出。到這里問題定位完成不是PWM capture配置錯(cuò)不是內(nèi)核讀轉(zhuǎn)速讀錯(cuò)就是純粹的風(fēng)扇機(jī)電故障。這個(gè)案例里的溫控策略也有問題為了靜音風(fēng)扇在50℃以下長期低速運(yùn)行低速工況下灰塵更容易附著在葉片和軸承上日積月累就卡死了。這是產(chǎn)品設(shè)計(jì)層面的隱患不只是風(fēng)扇質(zhì)量問題。7.3 根因確認(rèn)與修復(fù)方案最后我給這個(gè)項(xiàng)目做了三處改動(dòng)也推薦給所有類似場景的RK3588設(shè)備。第一溫控策略從低速常轉(zhuǎn)改成按需調(diào)速每周還加了一次30秒的全速自清潔周期利用離心力把葉片上的灰塵甩掉一部分。第二增加風(fēng)扇故障檢測邏輯PWM開度超過一定閾值而轉(zhuǎn)速異常偏低時(shí)立即觸發(fā)告警并主動(dòng)限制AI推理負(fù)載降低發(fā)熱。第三也是最關(guān)鍵的給設(shè)備加上了硬件看門狗和內(nèi)核panic自動(dòng)重啟。這樣即使故障真正再次發(fā)生導(dǎo)致重啟也只需要45秒左右就能恢復(fù)業(yè)務(wù)而不是等人工到場。這次排查給我最大的觸動(dòng)是散熱問題的根源往往不在散熱本身而在監(jiān)測缺失。如果一開始就盯著風(fēng)扇轉(zhuǎn)速和溫度趨勢故障是可以提前發(fā)現(xiàn)的。后來我在每個(gè)項(xiàng)目的設(shè)備驗(yàn)收清單里都加上了一條必須驗(yàn)證看門狗能復(fù)位系統(tǒng)必須驗(yàn)證風(fēng)扇在失速時(shí)能告警必須驗(yàn)證日志能在故障后留痕。做過這套Guardian體系之后我對RK3588邊緣AI設(shè)備的7×24穩(wěn)定性有了新的理解。所謂不死機(jī)不是追求設(shè)備永遠(yuǎn)不壞而是要讓每次故障都能在最短時(shí)間內(nèi)自愈把設(shè)備的不可用時(shí)間壓縮到分鐘級以內(nèi)。硬件壞了有看門狗兜底業(yè)務(wù)掛了有systemd拉起內(nèi)存泄漏了有cgroup隔離日志滿了有輪轉(zhuǎn)清理。把這些環(huán)節(jié)都打通再回頭看那些死機(jī)問題絕大多數(shù)都只是守護(hù)體系里的一個(gè)待完善節(jié)點(diǎn)。但也不要過度迷信守護(hù)機(jī)制本身——守護(hù)本質(zhì)上是在為系統(tǒng)的脆弱兜底更好的方向永遠(yuǎn)是在設(shè)計(jì)階段就把散熱、電源、存儲這些基礎(chǔ)功課做扎實(shí)讓Guardian從救命稻草變成保險(xiǎn)措施。