做嵌入式Linux開發(fā)這些年我踩過最多的坑不是功能實(shí)現(xiàn)不了而是板子跑起來了、功能也都能用但一到真機(jī)驗(yàn)證、量產(chǎn)階段各種性能問題就像洪水一樣涌出來。你盯著串口日志想定位問題結(jié)果日志本身就是瓶頸之一你以為是應(yīng)用代碼寫得爛查了一圈發(fā)現(xiàn)是內(nèi)核配置的問題你把優(yōu)化一通操作拉滿又發(fā)現(xiàn)啟動時間暴漲。這種“按下葫蘆浮起瓢”的體驗(yàn)凡是搞過Embedded Linux的人應(yīng)該都不陌生。這篇文章我就結(jié)合自己的實(shí)際經(jīng)歷把嵌入式Linux方案里常見的Performance Bottlenecks系統(tǒng)性地梳理一遍覆蓋CPU、內(nèi)存、I/O、啟動時間這幾個重災(zāi)區(qū)每個點(diǎn)都會給出排查工具、定位思路和實(shí)際優(yōu)化案例。無論你是剛?cè)胄械那度胧焦こ處熯€是被線上問題折磨已久的“老油條”這篇文章都值得你花十分鐘讀完至少能少走幾個月的彎路。1. 內(nèi)容整體設(shè)計與思路拆解1.1 嵌入式性能問題的特殊性在講具體瓶頸之前我想先聊一個認(rèn)知層面的問題嵌入式Linux的性能優(yōu)化和普通服務(wù)器端的性能調(diào)優(yōu)本質(zhì)上是兩碼事。服務(wù)器端資源相對充裕遇到瓶頸通常可以靠堆硬件解決——加CPU、加內(nèi)存、換SSD產(chǎn)品經(jīng)理那邊也好交代。但嵌入式方案是資源受限的CPU主頻固定、內(nèi)存焊死在板上、存儲用的是eMMC或者NAND Flash連電源余量都是按最低配置設(shè)計的。這意味著你必須在有限的資源內(nèi)把性能摳出來每一個微秒、每一兆內(nèi)存都可能有價值。還有一個更讓人頭疼的地方嵌入式系統(tǒng)通常有實(shí)時性要求。我的一個項(xiàng)目里主控CPU要同時處理HMI渲染、通信協(xié)議棧和運(yùn)動控制算法。HMI渲染被卡頓可以忍一下但運(yùn)動控制如果延遲抖動超過幾個毫秒設(shè)備直接就出安全問題了。這種“非實(shí)時任務(wù)拖垮實(shí)時任務(wù)”的場景在嵌入式Linux里非常典型。所以在排查嵌入式性能問題的時候不能只看平均負(fù)載更要關(guān)注“最壞情況延遲”和“尾部延遲”。有時候系統(tǒng)的平均CPU使用率只有60%但某個中斷響應(yīng)延遲已經(jīng)飆到幾十毫秒了。這種問題不通過專門的手段是根本看不出來的。1.2 性能優(yōu)化的核心思路先測量再優(yōu)化很多新手上來就喜歡“感覺哪里慢就優(yōu)化哪里”比如覺得系統(tǒng)卡是CPU頻率不夠直接把CPU調(diào)到最高頻結(jié)果電池掉電飛快、板子燙得能煎雞蛋問題卻沒解決。這是我見過最多的一種錯誤。正確的思路永遠(yuǎn)只有一個先量化再定位最后優(yōu)化。所謂量化就是把性能問題變成可測量的數(shù)值。系統(tǒng)啟動花了多長時間某個中斷響應(yīng)延遲是多少關(guān)鍵線程的調(diào)度延遲分布長什么樣內(nèi)存最高占用是多少只有把這些指標(biāo)量化了你才知道問題到底有多嚴(yán)重、優(yōu)化有沒有效果。接下來是定位。這一步需要借助工具鏈把瓶頸從“系統(tǒng)很卡”這種模糊的描述收斂到“某個進(jìn)程在某段時間內(nèi)發(fā)起了大量系統(tǒng)調(diào)用導(dǎo)致CPU占用飆升”這種精確的結(jié)論。perf、ftrace、strace這些工具在后面的章節(jié)我會詳細(xì)講怎么用。最后才是優(yōu)化。優(yōu)化手段從高到低有幾個層次算法優(yōu)化、架構(gòu)優(yōu)化、內(nèi)核配置優(yōu)化、硬件資源重新分配。最優(yōu)的方式是直接改應(yīng)用代碼因?yàn)椴挥|碰系統(tǒng)層、風(fēng)險最小但如果瓶頸在內(nèi)核或者配置層該改還是要改只是改動前必須在測試環(huán)境充分驗(yàn)證。我個人的習(xí)慣是同一個性能問題至少要量化兩次——優(yōu)化前一次優(yōu)化后一次。兩次數(shù)據(jù)對比才能確認(rèn)優(yōu)化真的生效了而不是“感覺變好了”。這個習(xí)慣幫我避免了很多次“白忙活”的尷尬。1.3 影響性能的關(guān)鍵維度劃分從工程實(shí)踐的角度我會把嵌入式Linux的性能瓶頸分成四大類CPU類瓶頸運(yùn)算能力不足、調(diào)度延遲過高、中斷風(fēng)暴、鎖競爭嚴(yán)重等。內(nèi)存類瓶頸物理內(nèi)存不足、內(nèi)存碎片化、分配延遲過高、swap抖動等。I/O類瓶頸閃存讀寫速度慢、文件系統(tǒng)日志開銷大、塊設(shè)備調(diào)度不均衡等。啟動類瓶頸內(nèi)核解壓耗時、initramfs加載慢、用戶態(tài)服務(wù)初始化串行化等。這四類問題在實(shí)際項(xiàng)目中很少單獨(dú)出現(xiàn)往往是互相牽制的。比如頻繁的I/O操作會拉高CPU占用內(nèi)存不足會導(dǎo)致OOM觸發(fā)、進(jìn)而引發(fā)I/O風(fēng)暴。所以排查的時候要有一個大局觀不能只盯著一項(xiàng)指標(biāo)看。還有一個維度經(jīng)常被忽略就是構(gòu)建與部署配置。同樣是代碼編譯優(yōu)化等級選-Os還是-O2跑起來性能差別不小內(nèi)核裁剪不當(dāng)沒用的驅(qū)動和子系統(tǒng)占著內(nèi)存、耗著電這些都屬于“隱形瓶頸”。我見過有的項(xiàng)目固件里明明沒有Wi-Fi模塊內(nèi)核還編譯了一堆Wi-Fi驅(qū)動白白占用內(nèi)存。這種問題改一行.config就能解決但沒人意識到。后面的內(nèi)容我就按這四個維度展開每個維度都會講原理、排查方法和實(shí)際案例。2. 核心瓶頸類型拆解與實(shí)操要點(diǎn)2.1 CPU類瓶頸從“跑滿”到“調(diào)度抖動”CPU類瓶頸是最直觀、最容易發(fā)現(xiàn)的因?yàn)镃PU使用率就放在那里一眼就能看到。但“看到CPU滿了”和“找到誰把CPU弄滿了、為什么弄滿”之間還有很長一段路。先說簡單的場景。用top命令看系統(tǒng)負(fù)載發(fā)現(xiàn)某個用戶態(tài)進(jìn)程CPU占用接近100%。這種情況通常是應(yīng)用層代碼出了Bug比如陷入死循環(huán)、頻繁輪詢、或者在事件循環(huán)里做了耗時操作。定位方法很簡單用perf top直接看當(dāng)前CPU熱點(diǎn)函數(shù)幾秒鐘就能找到問題函數(shù)。這種問題雖然好定位但我見過不少項(xiàng)目在代碼審查階段沒看出來等到測試階段才暴露白白浪費(fèi)了不少排查時間。復(fù)雜一點(diǎn)的是調(diào)度延遲問題。系統(tǒng)CPU看起來沒滿整體負(fù)載也不高但某個關(guān)鍵線程總是不能按時被調(diào)度導(dǎo)致外設(shè)通信超時或者控制周期抖動。這種問題的本質(zhì)是Linux默認(rèn)的CFS調(diào)度器是為“公平性”設(shè)計的它追求的是所有進(jìn)程共享CPU而不是優(yōu)先保證某個關(guān)鍵進(jìn)程的延遲。解決思路主要有兩種一是用線程優(yōu)先級RT調(diào)度策略SCHED_FIFO或SCHED_RR讓關(guān)鍵線程搶占普通進(jìn)程二是綁定CPU核心把關(guān)鍵線程固定在某個核上避免它被調(diào)度器在不同CPU之間遷移。我做過的一個項(xiàng)目里用cyclictest工具測量發(fā)現(xiàn)某個控制線程的最大調(diào)度延遲達(dá)到了400毫秒這顯然是不可接受的。當(dāng)時系統(tǒng)的CPU占用率只有40%所以問題不是資源不夠而是調(diào)度策略不對。解決辦法是把控制線程設(shè)成SCHED_FIFO優(yōu)先級90并且綁核到CPU2同時把其他非關(guān)鍵任務(wù)統(tǒng)統(tǒng)降級為SCHED_IDLE。改完之后最大調(diào)度延遲降到了150微秒以內(nèi)。這個案例很典型地說明嵌入式場景下不僅要看“CPU夠不夠用”還要看“CPU怎么被分配”。還有一種CPU類瓶頸是中斷風(fēng)暴。某個外設(shè)的中斷頻率異常高比如GPIO引腳沒有正確去抖、或者網(wǎng)卡收到了大量廣播包導(dǎo)致CPU頻繁進(jìn)入中斷處理程序。中斷的優(yōu)先級高于一切用戶態(tài)進(jìn)程所以中斷頻率過高會直接餓死業(yè)務(wù)線程。排查方式是用cat /proc/interrupts看哪個中斷號計數(shù)暴漲然后用echo禁用或屏蔽異常中斷源。這類問題在硬件不穩(wěn)定或者電磁干擾強(qiáng)的環(huán)境中特別常見。2.2 內(nèi)存類瓶頸碎片化、泄漏與分配延遲內(nèi)存瓶頸在嵌入式平臺上的表現(xiàn)形式和服務(wù)器很不一樣。服務(wù)器內(nèi)存不夠了可以看free命令然后加內(nèi)存或者調(diào)參數(shù)但嵌入式平臺內(nèi)存是固定的一旦出現(xiàn)內(nèi)存不足系統(tǒng)直接OOM觸發(fā)內(nèi)核的OOM Killer隨機(jī)殺掉一個倒霉進(jìn)程來騰內(nèi)存。這種“隨機(jī)殺人”在生產(chǎn)環(huán)境是絕對不可接受的。內(nèi)存類問題里面最隱蔽的是內(nèi)存碎片化。系統(tǒng)物理內(nèi)存總量充足但因?yàn)闆]有連續(xù)的物理頁面導(dǎo)致內(nèi)核無法分配大的連續(xù)內(nèi)存塊。這個問題在需要DMA操作的設(shè)備驅(qū)動中特別致命因?yàn)楹芏嘤布驞MA緩沖區(qū)在物理上連續(xù)。系統(tǒng)運(yùn)行幾天后某些驅(qū)動突然初始化失敗重啟就好了過幾天又壞了——這種典型的“運(yùn)行時間越長越容易出問題”的怪現(xiàn)象十有八九就是內(nèi)存碎片化。檢查碎片化的辦法是看/sys/kernel/debug/buddyinfo或/sys/kernel/debug/extfrag/index如果高orderorder3的連續(xù)頁面幾乎為0那基本可以確診了。改善手段包括啟用內(nèi)存規(guī)整功能在/etc/sysctl.conf里配置vm.compact_memory1、調(diào)整pageblock參數(shù)、或者在內(nèi)核配置中使能CMAContiguous Memory Allocator來專門管理大塊連續(xù)內(nèi)存的分配。再說說內(nèi)存泄漏。嵌入式Linux的應(yīng)用層內(nèi)存泄漏不像服務(wù)器端可以用Valgrind慢速排查很多時候你根本沒有那個運(yùn)行環(huán)境。我這邊常用的方法是在應(yīng)用里定期讀取/proc/self/status里的VmRSS把內(nèi)存占用的變化趨勢記錄下來分析是否持續(xù)增長更精細(xì)一點(diǎn)的做法是用tracepoint跟蹤kmalloc/kfree。內(nèi)存在嵌入式設(shè)備上是稀缺資源所以我的經(jīng)驗(yàn)是在開發(fā)階段就要把內(nèi)存監(jiān)控代碼寫進(jìn)應(yīng)用里這樣問題在上線前就能發(fā)現(xiàn)而不是等客戶用了半年后設(shè)備無故重啟才來溯源。還有一個經(jīng)常被忽略的點(diǎn)是分配延遲。在實(shí)時性要求高的場景里malloc()可能導(dǎo)致進(jìn)程進(jìn)入內(nèi)核態(tài)去申請內(nèi)存頁這個過程有時候會觸發(fā)內(nèi)存回收內(nèi)存頁換出消耗的時間可能是幾十微秒甚至幾毫秒。對于控制回路來說這種延遲是不能接受的。解決思路是啟動階段預(yù)分配內(nèi)存池業(yè)務(wù)運(yùn)行時從內(nèi)存池里取內(nèi)存避免在關(guān)鍵路徑上調(diào)用malloc()。2.3 I/O類瓶頸閃存特性的影響遠(yuǎn)超你的想象I/O瓶頸在嵌入式Linux里可以說是“最容易被低估”的一類問題。很多工程師習(xí)慣了PC上NVMe SSD的隨機(jī)讀性能下意識地認(rèn)為存儲不是瓶頸。但嵌入式平臺上用的eMMC、NAND Flash隨機(jī)小文件讀寫的速度可能只有幾十MB/s隨機(jī)寫IOPS更是低到感人。我做過一個數(shù)據(jù)記錄類產(chǎn)品需求是每秒鐘往Flash寫一條約4KB的日志。代碼很簡單就是open、write、fsync、close。跑起來后發(fā)現(xiàn)CPU占用率高達(dá)30%而且寫入速率經(jīng)常跟不上。一開始我以為Flash硬件有問題后來用strace一分析發(fā)現(xiàn)每次write之后調(diào)用的fsync會把數(shù)據(jù)強(qiáng)制刷到物理介質(zhì)上而Flash的塊擦除和寫入開銷遠(yuǎn)大于普通磁盤導(dǎo)致每次fsync都要卡好久。解決方案有兩層。第一層是代碼層面把日志先緩存到內(nèi)存環(huán)形緩沖區(qū)里攢夠批量數(shù)據(jù)后一次性寫入避免頻繁的小I/O第二層是文件系統(tǒng)層面換用更適合Flash場景的日志策略減少元數(shù)據(jù)更新的頻率。這樣一來同樣4KB/條的日志CPU占用降到了5%寫入速率也完全達(dá)標(biāo)了。文件系統(tǒng)選型也是嵌入式I/O優(yōu)化的關(guān)鍵環(huán)節(jié)。傳統(tǒng)ext4在全盤日志dataordered或datajournal模式下每筆寫入都要先寫日志再寫數(shù)據(jù)這在Flash上會造成嚴(yán)重的寫放大和延遲。我的建議是如果是只讀場景優(yōu)先考慮squashfs、erofs這類只讀壓縮文件系統(tǒng)如果是讀寫但數(shù)據(jù)不需要掉電保護(hù)可以選用ext4的datawriteback模式或者干脆上ubifs這種專為Flash設(shè)計的文件系統(tǒng)。另外還有塊層調(diào)度器的選擇。Linux內(nèi)核里有三種I/O調(diào)度器none、mq-deadline、bfq。在嵌入式設(shè)備上如果你用的是eMMC這類閃存設(shè)備本身已經(jīng)內(nèi)置了復(fù)雜的FTL映射和磨損均衡算法內(nèi)核層的調(diào)度器基本幫不上忙反而會引入額外開銷。所以我一般會直接設(shè)為none模式讓請求直通設(shè)備層減少一層軟件開銷。2.4 啟動時間瓶頸每一毫秒都要摳啟動時間是嵌入式Linux方案最容易被客戶感知的指標(biāo)之一。設(shè)備上電到主界面出現(xiàn)如果超過三秒用戶體驗(yàn)就很差在車載、工控這些領(lǐng)域啟動時間甚至要按百毫秒級別去要求。但Linux系統(tǒng)啟動鏈路很長Bootloader → 內(nèi)核解壓 → 內(nèi)核初始化 → initramfs加載 → 用戶態(tài)服務(wù)啟動每一環(huán)都有時間開銷。優(yōu)化啟動時間的第一步是先把各部分耗時量化出來。硬件上我會在啟動各階段的關(guān)鍵節(jié)點(diǎn)加GPIO翻轉(zhuǎn)點(diǎn)用示波器直接測量軟件上有Bootchart/Bootgraph工具可以自動收集各進(jìn)程的啟動耗時。拿到數(shù)據(jù)后通常會發(fā)現(xiàn)耗時大頭集中在這么幾處內(nèi)核解壓如果內(nèi)核太大、initramfs中庫和驅(qū)動的加載、systemd服務(wù)的串行啟動、Qt等GUI框架的初始化。針對內(nèi)核解壓耗時最直接的手段是減少內(nèi)核體積。把不需要的驅(qū)動和子系統(tǒng)全部裁掉開啟內(nèi)核的LTO優(yōu)化選項(xiàng)壓縮算法從gzip換用lz4或lzma。根據(jù)我的測試同樣的內(nèi)核用gzip壓縮的大約耗時400ms解壓改成lz4后能降到200ms左右代價是固件體積變大自行權(quán)衡。針對用戶態(tài)啟動慢主流手段是把systemd里非關(guān)鍵服務(wù)干掉或者延遲觸發(fā)只保留最核心的幾個服務(wù)立即啟動更激進(jìn)的方案是跳過initramfs直接讓內(nèi)核掛載根文件系統(tǒng)。如果用的是根文件系統(tǒng)在eMMC上的方案還可以在啟動階段只掛載只讀的squashfs鏡像需要讀寫的目錄再單獨(dú)掛overlayfs這樣文件系統(tǒng)掛載速度快得多。我在一個行車記錄儀項(xiàng)目里做啟動優(yōu)化原始啟動時間接近4秒。通過內(nèi)核裁剪省掉700ms換用lz4解壓省掉200msinitramfs精簡庫文件省掉500mssystemd服務(wù)精簡省掉1.2秒最終壓到了1.4秒。整個過程沒有改任何應(yīng)用代碼收益卻非常明顯。3. 工具鏈與排查方法解析3.1 基礎(chǔ)工具top、free、iostat的基礎(chǔ)與進(jìn)階用法排查性能問題我首先會用到一套“三板斧”工具top、free、iostat。這三個命令系統(tǒng)自帶部署方便在任何嵌入式環(huán)境里都能跑。top用來觀察CPU占用和內(nèi)存占用。但我的習(xí)慣不是看一眼CPU Total就完事而是重點(diǎn)關(guān)注每個進(jìn)程在用戶態(tài)us、內(nèi)核態(tài)sy以及等待I/Owa上的時間分配。us高說明是用戶態(tài)計算密集sy高說明是系統(tǒng)調(diào)用或內(nèi)核路徑開銷大wa高說明瓶頸在存儲I/O。這三個值的組合能快速把問題方向定下來。free主要看內(nèi)存的使用情況。但嵌入式環(huán)境下我特別關(guān)注available這一列因?yàn)樗攀恰罢嬲捎谩钡膬?nèi)存而不是free這一列。Linux會盡量把空閑內(nèi)存用作page cache來提升I/O性能所以free列很小不代表內(nèi)存不夠只有available很小才是真正的內(nèi)存不足。iostat可以查看塊設(shè)備的實(shí)時I/O情況包括tps每秒傳輸次數(shù)、KB_read/s、KB_wrtn/s以及await平均I/O等待時間。如果await值很大說明I/O請求在隊列里等待時間很長設(shè)備處理能力跟不上如果是r_await和w_await差異很大則要考慮閃存的讀寫性能不對稱問題。這三板斧雖然基礎(chǔ)但在大多數(shù)嵌入式項(xiàng)目里用它們就能定位到80%的問題。只有剩下的20%疑難雜癥才需要動用后面講的perf、ftrace這些重型武器。3.2 高級追蹤工具perf、ftrace與trace-cmd實(shí)戰(zhàn)perf是Linux性能分析的“核武器”它利用硬件性能計數(shù)器和內(nèi)核tracepoint來做采樣分析。在嵌入式平臺上的用法通常是這樣# 采集10秒CPU熱點(diǎn)數(shù)據(jù) perf top # 記錄全系統(tǒng)性能數(shù)據(jù)采樣頻率99Hz perf record -g -F 99 -- sleep 10 # 生成報告 perf report-g參數(shù)表示記錄調(diào)用棧這樣能把“哪個函數(shù)調(diào)用了哪個函數(shù)”的完整鏈條抓出來。比如系統(tǒng)卡頓你用perf record一拍可能發(fā)現(xiàn)是某個驅(qū)動在中斷上下文里做了大量線性搜索熱點(diǎn)函數(shù)一目了然。perf好是好但版本依賴內(nèi)核源碼嵌入式交叉編譯有時候比較折騰。如果不想編譯工具鏈可以用ftrace。ftrace是內(nèi)核自帶的事件追蹤器不需要額外安裝任何用戶態(tài)工具只需要內(nèi)核開啟了對應(yīng)的CONFIG_FTRACE配置項(xiàng)。我常用的是ftrace的function_graph功能它可以追蹤指定函數(shù)的調(diào)用耗時# 掛載tracefs mount -t tracefs nodev /sys/kernel/tracing # 追蹤某個特定內(nèi)核函數(shù) echo function_graph /sys/kernel/tracing/current_tracer echo do_sys_open /sys/kernel/tracing/set_ftrace_filter echo 1 /sys/kernel/tracing/tracing_on cat /sys/kernel/tracing/tracetrace-cmd則是ftrace的封裝工具提供更友好的命令行交互可以按事件名抓取數(shù)據(jù)并生成報告。我之前定位一個USB驅(qū)動偶發(fā)卡頓的問題就是靠trace-cmd抓到的usb_submit_urb函數(shù)調(diào)用延遲分布找到根因的。3.3 系統(tǒng)調(diào)用追蹤與啟動分析利器strace是我對應(yīng)用層問題定位的首選工具。它可以記錄進(jìn)程發(fā)起的每一次系統(tǒng)調(diào)用、參數(shù)和返回值在排查“程序卡在哪個系統(tǒng)調(diào)用”這類問題上效果極為顯著。嵌入式環(huán)境里strace一般放在debugfs分區(qū)里只在調(diào)試時掛載使用量產(chǎn)固件里不要打進(jìn)去因?yàn)閟trace會讓目標(biāo)進(jìn)程的運(yùn)行速度下降一到兩個數(shù)量級。啟動時間的專項(xiàng)分析工具我用得比較多的有兩個Bootchart和systemd-analyze。Bootchart會從啟動開始記錄每個進(jìn)程的CPU、內(nèi)存、I/O時間線生成SVG圖。從圖里能直觀看到哪些服務(wù)在并行執(zhí)行、哪些服務(wù)被串行等待拖累了。systemd-analyze更精準(zhǔn)它直接讀取systemd的啟動事件記錄# 展示各服務(wù)啟動時間 systemd-analyze blame # 展示服務(wù)依賴關(guān)鍵路徑 systemd-analyze critical-chainblame會按各服務(wù)的耗時從高到低排列critical-chain則能看出整個啟動鏈路里最長的關(guān)鍵路徑。一般來說服務(wù)啟動慢的要么是依賴等待比如等待某個設(shè)備節(jié)點(diǎn)出現(xiàn)要么是自身初始化太重這兩者都能通過這些命令快速定位。3.4 其他值得擁有的工具latencytop與cyclictest前面提到的工具主要面向“性能”問題但如果你的系統(tǒng)是實(shí)時性要求高的場景還需要重點(diǎn)關(guān)注“延遲”問題。這時候兩個工具會派上大用場latencytop和cyclictest。latencytop可以系統(tǒng)級地展示“哪些內(nèi)核路徑導(dǎo)致了用戶態(tài)進(jìn)程長時間無法運(yùn)行”它的輸出類似top命令但排序依據(jù)是進(jìn)程在等待延遲上的時間開銷而不是CPU占用。cyclictest是實(shí)時性測試領(lǐng)域的標(biāo)桿工具用來測量內(nèi)核調(diào)度延遲。它會創(chuàng)建一個高優(yōu)先級線程按固定周期睡眠然后測量實(shí)際喚醒時間與預(yù)期時間的偏差這個偏差就是調(diào)度延遲。我的習(xí)慣是讓它跑24小時以上統(tǒng)計最大延遲值只有最大延遲在可接受范圍內(nèi)這個系統(tǒng)才敢說滿足實(shí)時性要求。4. 實(shí)戰(zhàn)案例復(fù)盤與避坑指南4.1 案例一一個“永遠(yuǎn)跑滿”的CPU核心一個工業(yè)網(wǎng)關(guān)項(xiàng)目ARM四核A53平臺運(yùn)行過程中發(fā)現(xiàn)CPU3使用率幾乎一直是100%但CPU0-2都很空閑。客戶抱怨功耗偏高、機(jī)身發(fā)燙要求排查。我先用perf top采樣了幾秒結(jié)果熱點(diǎn)函數(shù)指向了一個內(nèi)核驅(qū)動模塊——某個傳感器驅(qū)動的中斷處理函數(shù)。這個驅(qū)動在每次中斷觸發(fā)時都去讀取一個慢速I2C設(shè)備中斷頻率極高所以CPU3被持續(xù)占用。我繼續(xù)看/proc/interrupts確認(rèn)中斷次數(shù)果然是網(wǎng)卡之外中斷次數(shù)最高的。深入看代碼后發(fā)現(xiàn)驅(qū)動作者在中斷處理函數(shù)里做了大量的輪詢式讀取這種寫法在快速中斷場景下非常糟糕。解決方式分兩步第一步把中斷處理函數(shù)里的底部處理邏輯移到tasklet或workqueue里讓中斷處理只做最少的確認(rèn)工作第二步降低I2C設(shè)備的采樣頻率并對采樣數(shù)據(jù)做滑動平均濾波避免對噪聲過度反應(yīng)。改完之后CPU3使用率從100%降到了8%功耗問題隨之消失。這個案例的教訓(xùn)是嵌入式平臺上的中斷處理函數(shù)不是隨便寫的任何不能在幾十微秒內(nèi)完成的操作都必須考慮延遲到非中斷上下文執(zhí)行。4.2 案例二啟動時間從4.2秒優(yōu)化到1.4秒某個帶屏的消費(fèi)類設(shè)備需求是上電到顯示主界面不超過2秒。原始版本實(shí)測4.2秒差得有點(diǎn)遠(yuǎn)整個優(yōu)化過程我按啟動鏈路分了三步走。第一步是Bootloader階段。U-Boot從Flash加載內(nèi)核鏡像原來的壓縮模式是gzip我改成了lz4這一步省了約200ms同時裁剪了U-Boot里不需要的驅(qū)動省了100ms。第二步是內(nèi)核階段。原來內(nèi)核打了大量沒用的驅(qū)動包括一些根本不存在的外設(shè)控制器驅(qū)動全部裁剪掉內(nèi)核映像從6MB減到了3.2MB解壓和初始化時間大幅下降這一塊總共省了約1秒。第三步是用戶態(tài)階段。原來的做法是systemd把十幾個服務(wù)全部按默認(rèn)方式串行啟動其中有藍(lán)牙、網(wǎng)絡(luò)、云平臺連接等但這些服務(wù)在首屏顯示之前根本不需要。我把顯示服務(wù)設(shè)為最優(yōu)先啟動其他服務(wù)全部設(shè)為延遲到首屏顯示后再啟動同時把initramfs里用不到的庫文件全部刪掉。這部分省了1.7秒。最終啟動時間穩(wěn)定在1.4秒。整個優(yōu)化過程總結(jié)起來就是一句話把不需要的東西都去掉把關(guān)鍵的路徑縮短。4.3 案例三內(nèi)存碎片化導(dǎo)致驅(qū)動隨機(jī)初始化失敗網(wǎng)卡驅(qū)動在某嵌入式設(shè)備上時常初始化失敗報的是DMA緩沖區(qū)分配錯誤。但系統(tǒng)空閑內(nèi)存明明還有200MB以上重啟后能正常跑一兩天后故障復(fù)現(xiàn)概率越來越大。我一開始懷疑是內(nèi)存泄漏但排查了一圈沒有發(fā)現(xiàn)明顯泄漏。后來偶然用cat /proc/buddyinfo看了一眼發(fā)現(xiàn)order3的連續(xù)頁面數(shù)量為0才終于明白問題的本質(zhì)系統(tǒng)內(nèi)存碎片化嚴(yán)重盡管總空閑內(nèi)存不少但無法滿足驅(qū)動的大塊連續(xù)內(nèi)存分配請求。這種問題的根源在于系統(tǒng)長時間運(yùn)行后內(nèi)存頁面被頻繁申請和釋放大的連續(xù)塊被逐漸切割成碎片。內(nèi)核對頁面分配無能為力的話就只能報錯。我用的解決方法是在內(nèi)核配置里確認(rèn)開啟CMA并將網(wǎng)卡的DMA緩沖區(qū)分配改為從CMA區(qū)域分配同時在內(nèi)存壓力大的時候定期觸發(fā)內(nèi)存規(guī)整echo 1 /proc/sys/vm/compact_memory。改完以后連續(xù)跑了兩個月故障沒有再出現(xiàn)。這個案例給我們的啟示是嵌入式方案在選型階段就要考慮設(shè)備的運(yùn)行時長和內(nèi)存行為規(guī)劃好DMA內(nèi)存的分配策略。等到現(xiàn)場出問題了再排查代價會高得多。4.4 常見問題速查表現(xiàn)象可能原因排查命令/工具解決思路單個核心跑滿中斷風(fēng)暴/調(diào)度不均cat /proc/interrupts綁核、延遲中斷處理系統(tǒng)卡頓但CPU不高鎖競爭/調(diào)度延遲perf sched、cyclictest調(diào)整優(yōu)先級、減少共享鎖內(nèi)存充足但分配失敗內(nèi)存碎片化cat /proc/buddyinfo啟用CMA、內(nèi)存規(guī)整寫入慢且CPU高fsync頻繁/文件系統(tǒng)日志strace、iostat批量寫入、調(diào)整日志模式設(shè)備越用越卡內(nèi)存泄漏定期記錄VmRSS定位泄漏點(diǎn)并修復(fù)啟動慢服務(wù)串行/內(nèi)核過大systemd-analyze blame裁剪內(nèi)核、并行化服務(wù)網(wǎng)絡(luò)時延抖動大中斷處理不當(dāng)/調(diào)度延遲perf、cyclictest網(wǎng)卡中斷綁核、RT補(bǔ)丁4.5 一些容易忽略的“隱形”瓶頸除了上面這些明面上的瓶頸還有幾個“隱形”問題我覺得值得單獨(dú)拎出來說一下。第一個是調(diào)試串口的拖累。很多嵌入式工程師習(xí)慣在代碼里到處加printf打印但串口波特率通常只有115200約合每秒十幾KB。如果代碼里大量打印光串口輸出就能把CPU拖垮因?yàn)槊枯敵鲆粋€字符CPU都要等待串口FIFO刷新。我見過一個系統(tǒng)僅僅是因?yàn)檎{(diào)試打印太多CPU占用就多了20%。量產(chǎn)固件里建議關(guān)掉所有調(diào)試打印或者用環(huán)形緩沖區(qū)在內(nèi)存里暫存日志按需導(dǎo)出。第二個是編譯優(yōu)化等級。內(nèi)核和應(yīng)用默認(rèn)的編譯選項(xiàng)是-O2但在嵌入式場景建議認(rèn)真試試-Os優(yōu)化體積。體積變小意味著緩存命中率提高、啟動時內(nèi)核加載時間變短有時候反而會比-O2更快。我在幾個項(xiàng)目里都驗(yàn)證過-Os編譯的內(nèi)核在某些負(fù)載下性能比-O2更好還節(jié)省了Flash空間。第三個是電源管理策略?，F(xiàn)在的ARM SoC都支持動態(tài)調(diào)頻調(diào)壓DVFS。有時性能問題不是硬件不夠強(qiáng)而是CPU降頻了——可能是溫控策略太激進(jìn)可能是電源管理框架把CPU調(diào)到了低功耗檔位。遇到性能不達(dá)預(yù)期、但硬件配置客觀夠用的場景一定要先檢查/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq確認(rèn)CPU是否跑在預(yù)期頻率上。5. 一個值得嘗試的調(diào)優(yōu)順序與檢查清單我在實(shí)際項(xiàng)目中總結(jié)了一套相對固定的排查流程分享出來供你參考。遇到性能問題按這個順序走基本不會漏掉大方向確認(rèn)性能問題可量化先明確“慢”的定義。是啟動慢是某個操作響應(yīng)慢是處理吞吐不夠用指標(biāo)定義清楚比如“從觸發(fā)到響應(yīng)超過500ms”。收集基礎(chǔ)數(shù)據(jù)跑top看CPU分布free看內(nèi)存iostat看I/Odmesg看內(nèi)核有沒有報警。應(yīng)用層定位如果CPU高用perf top看熱點(diǎn)如果進(jìn)程卡住用strace抓系統(tǒng)調(diào)用。先排除應(yīng)用層的低級問題。內(nèi)核層定位應(yīng)用層沒問題再往內(nèi)核里挖用ftrace追蹤關(guān)鍵路徑用/proc/interrupts看中斷分布。針對定位結(jié)果做優(yōu)化每次只改一個變量改完重新量化對比確認(rèn)沒有引入新的問題。驗(yàn)證長期穩(wěn)定性性能優(yōu)化完成不代表結(jié)束尤其是涉及內(nèi)存、實(shí)時性的改動要在目標(biāo)環(huán)境上持續(xù)運(yùn)行幾天確認(rèn)無回歸。這個流程看起來簡單但很多人做不到原因就是“跳步”。看到CPU高就直接改代碼看到啟動慢就盲目裁剪內(nèi)核沒有先定位清楚最后往往是白忙活甚至越改越糟。另外一個常被忽略的點(diǎn)是優(yōu)化時要把“需求指標(biāo)”寫清楚?？蛻粽f“我要系統(tǒng)跑得快”這個描述沒有意義。你得追問您是要啟動快操作響應(yīng)快還是持續(xù)業(yè)務(wù)吞吐高每個指標(biāo)對應(yīng)的優(yōu)化路徑完全不同選錯方向就是在浪費(fèi)團(tuán)隊時間。我每次在項(xiàng)目啟動前都會把性能指標(biāo)寫成一個正式的表格發(fā)給客戶確認(rèn)簽字這樣后續(xù)優(yōu)化有據(jù)可依也避免做無用功。做嵌入式Linux這些年我最大的體會是性能問題從來不是單點(diǎn)問題而是一個系統(tǒng)性問題。CPU、內(nèi)存、I/O、啟動時間、實(shí)時性每個維度都像木桶的一塊板哪塊短了水都會漏。但好在大部分瓶頸都有跡可循解法也都是成熟的技術(shù)關(guān)鍵在于你有沒有耐心去測量、定位、驗(yàn)證。還有一個心得優(yōu)化這件事越早介入成本越低。很多性能問題在設(shè)計階段就可以避免比如選型時評估內(nèi)存和存儲余量、設(shè)計時規(guī)劃好中斷優(yōu)先級、編碼時注意鎖粒度和系統(tǒng)調(diào)用頻率。等到設(shè)備量產(chǎn)了再出性能問題那種被客戶催著、被領(lǐng)導(dǎo)盯著的感覺真的希望你永遠(yuǎn)不要體驗(yàn)。