做嵌入式Linux開發(fā)這些年我踩過最多的坑不是功能實現(xiàn)不了而是板子跑起來了、功能也都能用但一到真機驗證、量產(chǎn)階段各種性能問題就像洪水一樣涌出來。你盯著串口日志想定位問題結(jié)果日志本身就是瓶頸之一你以為是應(yīng)用代碼寫得爛查了一圈發(fā)現(xiàn)是內(nèi)核配置的問題你把優(yōu)化一通操作拉滿又發(fā)現(xiàn)啟動時間暴漲。這種“按下葫蘆浮起瓢”的體驗凡是搞過Embedded Linux的人應(yīng)該都不陌生。這篇文章我就結(jié)合自己的實際經(jīng)歷把嵌入式Linux方案里常見的Performance Bottlenecks系統(tǒng)性地梳理一遍覆蓋CPU、內(nèi)存、I/O、啟動時間這幾個重災(zāi)區(qū)每個點都會給出排查工具、定位思路和實際優(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)通常有實時性要求。我的一個項目里主控CPU要同時處理HMI渲染、通信協(xié)議棧和運動控制算法。HMI渲染被卡頓可以忍一下但運動控制如果延遲抖動超過幾個毫秒設(shè)備直接就出安全問題了。這種“非實時任務(wù)拖垮實時任務(wù)”的場景在嵌入式Linux里非常典型。所以在排查嵌入式性能問題的時候不能只看平均負載更要關(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é)果電池掉電飛快、板子燙得能煎雞蛋問題卻沒解決。這是我見過最多的一種錯誤。正確的思路永遠只有一個先量化再定位最后優(yōu)化。所謂量化就是把性能問題變成可測量的數(shù)值。系統(tǒng)啟動花了多長時間某個中斷響應(yīng)延遲是多少關(guān)鍵線程的調(diào)度延遲分布長什么樣內(nèi)存最高占用是多少只有把這些指標(biāo)量化了你才知道問題到底有多嚴(yán)重、優(yōu)化有沒有效果。接下來是定位。這一步需要借助工具鏈把瓶頸從“系統(tǒng)很卡”這種模糊的描述收斂到“某個進程在某段時間內(nèi)發(fā)起了大量系統(tǒng)調(diào)用導(dǎo)致CPU占用飆升”這種精確的結(jié)論。perf、ftrace、strace這些工具在后面的章節(jié)我會詳細講怎么用。最后才是優(yōu)化。優(yōu)化手段從高到低有幾個層次算法優(yōu)化、架構(gòu)優(yōu)化、內(nèi)核配置優(yōu)化、硬件資源重新分配。最優(yōu)的方式是直接改應(yīng)用代碼因為不觸碰系統(tǒng)層、風(fēng)險最小但如果瓶頸在內(nèi)核或者配置層該改還是要改只是改動前必須在測試環(huán)境充分驗證。我個人的習(xí)慣是同一個性能問題至少要量化兩次——優(yōu)化前一次優(yōu)化后一次。兩次數(shù)據(jù)對比才能確認(rèn)優(yōu)化真的生效了而不是“感覺變好了”。這個習(xí)慣幫我避免了很多次“白忙活”的尷尬。1.3 影響性能的關(guān)鍵維度劃分從工程實踐的角度我會把嵌入式Linux的性能瓶頸分成四大類CPU類瓶頸運算能力不足、調(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ù)初始化串行化等。這四類問題在實際項目中很少單獨出現(xiàn)往往是互相牽制的。比如頻繁的I/O操作會拉高CPU占用內(nèi)存不足會導(dǎo)致OOM觸發(fā)、進而引發(fā)I/O風(fēng)暴。所以排查的時候要有一個大局觀不能只盯著一項指標(biāo)看。還有一個維度經(jīng)常被忽略就是構(gòu)建與部署配置。同樣是代碼編譯優(yōu)化等級選-Os還是-O2跑起來性能差別不小內(nèi)核裁剪不當(dāng)沒用的驅(qū)動和子系統(tǒng)占著內(nèi)存、耗著電這些都屬于“隱形瓶頸”。我見過有的項目固件里明明沒有Wi-Fi模塊內(nèi)核還編譯了一堆Wi-Fi驅(qū)動白白占用內(nèi)存。這種問題改一行.config就能解決但沒人意識到。后面的內(nèi)容我就按這四個維度展開每個維度都會講原理、排查方法和實際案例。2. 核心瓶頸類型拆解與實操要點2.1 CPU類瓶頸從“跑滿”到“調(diào)度抖動”CPU類瓶頸是最直觀、最容易發(fā)現(xiàn)的因為CPU使用率就放在那里一眼就能看到。但“看到CPU滿了”和“找到誰把CPU弄滿了、為什么弄滿”之間還有很長一段路。先說簡單的場景。用top命令看系統(tǒng)負載發(fā)現(xiàn)某個用戶態(tài)進程CPU占用接近100%。這種情況通常是應(yīng)用層代碼出了Bug比如陷入死循環(huán)、頻繁輪詢、或者在事件循環(huán)里做了耗時操作。定位方法很簡單用perf top直接看當(dāng)前CPU熱點函數(shù)幾秒鐘就能找到問題函數(shù)。這種問題雖然好定位但我見過不少項目在代碼審查階段沒看出來等到測試階段才暴露白白浪費了不少排查時間。復(fù)雜一點的是調(diào)度延遲問題。系統(tǒng)CPU看起來沒滿整體負載也不高但某個關(guān)鍵線程總是不能按時被調(diào)度導(dǎo)致外設(shè)通信超時或者控制周期抖動。這種問題的本質(zhì)是Linux默認(rèn)的CFS調(diào)度器是為“公平性”設(shè)計的它追求的是所有進程共享CPU而不是優(yōu)先保證某個關(guān)鍵進程的延遲。解決思路主要有兩種一是用線程優(yōu)先級RT調(diào)度策略SCHED_FIFO或SCHED_RR讓關(guān)鍵線程搶占普通進程二是綁定CPU核心把關(guān)鍵線程固定在某個核上避免它被調(diào)度器在不同CPU之間遷移。我做過的一個項目里用cyclictest工具測量發(fā)現(xiàn)某個控制線程的最大調(diào)度延遲達到了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頻繁進入中斷處理程序。中斷的優(yōu)先級高于一切用戶態(tài)進程所以中斷頻率過高會直接餓死業(yè)務(wù)線程。排查方式是用cat /proc/interrupts看哪個中斷號計數(shù)暴漲然后用echo禁用或屏蔽異常中斷源。這類問題在硬件不穩(wěn)定或者電磁干擾強的環(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隨機殺掉一個倒霉進程來騰內(nèi)存。這種“隨機殺人”在生產(chǎn)環(huán)境是絕對不可接受的。內(nèi)存類問題里面最隱蔽的是內(nèi)存碎片化。系統(tǒng)物理內(nèi)存總量充足但因為沒有連續(xù)的物理頁面導(dǎo)致內(nèi)核無法分配大的連續(xù)內(nèi)存塊。這個問題在需要DMA操作的設(shè)備驅(qū)動中特別致命因為很多硬件要求DMA緩沖區(qū)在物理上連續(xù)。系統(tǒng)運行幾天后某些驅(qū)動突然初始化失敗重啟就好了過幾天又壞了——這種典型的“運行時間越長越容易出問題”的怪現(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慢速排查很多時候你根本沒有那個運行環(huán)境。我這邊常用的方法是在應(yīng)用里定期讀取/proc/self/status里的VmRSS把內(nèi)存占用的變化趨勢記錄下來分析是否持續(xù)增長更精細一點的做法是用tracepoint跟蹤kmalloc/kfree。內(nèi)存在嵌入式設(shè)備上是稀缺資源所以我的經(jīng)驗是在開發(fā)階段就要把內(nèi)存監(jiān)控代碼寫進應(yīng)用里這樣問題在上線前就能發(fā)現(xiàn)而不是等客戶用了半年后設(shè)備無故重啟才來溯源。還有一個經(jīng)常被忽略的點是分配延遲。在實時性要求高的場景里malloc()可能導(dǎo)致進程進入內(nèi)核態(tài)去申請內(nèi)存頁這個過程有時候會觸發(fā)內(nèi)存回收內(nèi)存頁換出消耗的時間可能是幾十微秒甚至幾毫秒。對于控制回路來說這種延遲是不能接受的。解決思路是啟動階段預(yù)分配內(nèi)存池業(yè)務(wù)運行時從內(nèi)存池里取內(nèi)存避免在關(guān)鍵路徑上調(diào)用malloc()。2.3 I/O類瓶頸閃存特性的影響遠超你的想象I/O瓶頸在嵌入式Linux里可以說是“最容易被低估”的一類問題。很多工程師習(xí)慣了PC上NVMe SSD的隨機讀性能下意識地認(rèn)為存儲不是瓶頸。但嵌入式平臺上用的eMMC、NAND Flash隨機小文件讀寫的速度可能只有幾十MB/s隨機寫IOPS更是低到感人。我做過一個數(shù)據(jù)記錄類產(chǎn)品需求是每秒鐘往Flash寫一條約4KB的日志。代碼很簡單就是open、write、fsync、close。跑起來后發(fā)現(xiàn)CPU占用率高達30%而且寫入速率經(jīng)常跟不上。一開始我以為Flash硬件有問題后來用strace一分析發(fā)現(xiàn)每次write之后調(diào)用的fsync會把數(shù)據(jù)強制刷到物理介質(zhì)上而Flash的塊擦除和寫入開銷遠大于普通磁盤導(dǎo)致每次fsync都要卡好久。解決方案有兩層。第一層是代碼層面把日志先緩存到內(nèi)存環(huán)形緩沖區(qū)里攢夠批量數(shù)據(jù)后一次性寫入避免頻繁的小I/O第二層是文件系統(tǒng)層面換用更適合Flash場景的日志策略減少元數(shù)據(jù)更新的頻率。這樣一來同樣4KB/條的日志CPU占用降到了5%寫入速率也完全達標(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ù)不需要掉電保護可以選用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)如果超過三秒用戶體驗就很差在車載、工控這些領(lǐng)域啟動時間甚至要按百毫秒級別去要求。但Linux系統(tǒng)啟動鏈路很長Bootloader → 內(nèi)核解壓 → 內(nèi)核初始化 → initramfs加載 → 用戶態(tài)服務(wù)啟動每一環(huán)都有時間開銷。優(yōu)化啟動時間的第一步是先把各部分耗時量化出來。硬件上我會在啟動各階段的關(guān)鍵節(jié)點加GPIO翻轉(zhuǎn)點用示波器直接測量軟件上有Bootchart/Bootgraph工具可以自動收集各進程的啟動耗時。拿到數(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)化選項壓縮算法從gzip換用lz4或lzma。根據(jù)我的測試同樣的內(nèi)核用gzip壓縮的大約耗時400ms解壓改成lz4后能降到200ms左右代價是固件體積變大自行權(quán)衡。針對用戶態(tài)啟動慢主流手段是把systemd里非關(guān)鍵服務(wù)干掉或者延遲觸發(fā)只保留最核心的幾個服務(wù)立即啟動更激進的方案是跳過initramfs直接讓內(nèi)核掛載根文件系統(tǒng)。如果用的是根文件系統(tǒng)在eMMC上的方案還可以在啟動階段只掛載只讀的squashfs鏡像需要讀寫的目錄再單獨掛overlayfs這樣文件系統(tǒ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ǔ)與進階用法排查性能問題我首先會用到一套“三板斧”工具top、free、iostat。這三個命令系統(tǒng)自帶部署方便在任何嵌入式環(huán)境里都能跑。top用來觀察CPU占用和內(nèi)存占用。但我的習(xí)慣不是看一眼CPU Total就完事而是重點關(guā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這一列因為它才是“真正可用”的內(nèi)存而不是free這一列。Linux會盡量把空閑內(nèi)存用作page cache來提升I/O性能所以free列很小不代表內(nèi)存不夠只有available很小才是真正的內(nèi)存不足。iostat可以查看塊設(shè)備的實時I/O情況包括tps每秒傳輸次數(shù)、KB_read/s、KB_wrtn/s以及await平均I/O等待時間。如果await值很大說明I/O請求在隊列里等待時間很長設(shè)備處理能力跟不上如果是r_await和w_await差異很大則要考慮閃存的讀寫性能不對稱問題。這三板斧雖然基礎(chǔ)但在大多數(shù)嵌入式項目里用它們就能定位到80%的問題。只有剩下的20%疑難雜癥才需要動用后面講的perf、ftrace這些重型武器。3.2 高級追蹤工具perf、ftrace與trace-cmd實戰(zhàn)perf是Linux性能分析的“核武器”它利用硬件性能計數(shù)器和內(nèi)核tracepoint來做采樣分析。在嵌入式平臺上的用法通常是這樣# 采集10秒CPU熱點數(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ū)動在中斷上下文里做了大量線性搜索熱點函數(shù)一目了然。perf好是好但版本依賴內(nèi)核源碼嵌入式交叉編譯有時候比較折騰。如果不想編譯工具鏈可以用ftrace。ftrace是內(nèi)核自帶的事件追蹤器不需要額外安裝任何用戶態(tài)工具只需要內(nèi)核開啟了對應(yīng)的CONFIG_FTRACE配置項。我常用的是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)用層問題定位的首選工具。它可以記錄進程發(fā)起的每一次系統(tǒng)調(diào)用、參數(shù)和返回值在排查“程序卡在哪個系統(tǒng)調(diào)用”這類問題上效果極為顯著。嵌入式環(huán)境里strace一般放在debugfs分區(qū)里只在調(diào)試時掛載使用量產(chǎn)固件里不要打進去因為strace會讓目標(biāo)進程的運行速度下降一到兩個數(shù)量級。啟動時間的專項分析工具我用得比較多的有兩個Bootchart和systemd-analyze。Bootchart會從啟動開始記錄每個進程的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é)點出現(xiàn)要么是自身初始化太重這兩者都能通過這些命令快速定位。3.4 其他值得擁有的工具latencytop與cyclictest前面提到的工具主要面向“性能”問題但如果你的系統(tǒng)是實時性要求高的場景還需要重點關(guān)注“延遲”問題。這時候兩個工具會派上大用場latencytop和cyclictest。latencytop可以系統(tǒng)級地展示“哪些內(nèi)核路徑導(dǎo)致了用戶態(tài)進程長時間無法運行”它的輸出類似top命令但排序依據(jù)是進程在等待延遲上的時間開銷而不是CPU占用。cyclictest是實時性測試領(lǐng)域的標(biāo)桿工具用來測量內(nèi)核調(diào)度延遲。它會創(chuàng)建一個高優(yōu)先級線程按固定周期睡眠然后測量實際喚醒時間與預(yù)期時間的偏差這個偏差就是調(diào)度延遲。我的習(xí)慣是讓它跑24小時以上統(tǒng)計最大延遲值只有最大延遲在可接受范圍內(nèi)這個系統(tǒng)才敢說滿足實時性要求。4. 實戰(zhàn)案例復(fù)盤與避坑指南4.1 案例一一個“永遠跑滿”的CPU核心一個工業(yè)網(wǎng)關(guān)項目ARM四核A53平臺運行過程中發(fā)現(xiàn)CPU3使用率幾乎一直是100%但CPU0-2都很空閑?？蛻舯г构钠摺C身發(fā)燙要求排查。我先用perf top采樣了幾秒結(jié)果熱點函數(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秒某個帶屏的消費類設(shè)備需求是上電到顯示主界面不超過2秒。原始版本實測4.2秒差得有點遠整個優(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)方式串行啟動其中有藍牙、網(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ū)動隨機初始化失敗網(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)長時間運行后內(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è)備的運行時長和內(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定位泄漏點并修復(fù)啟動慢服務(wù)串行/內(nèi)核過大systemd-analyze blame裁剪內(nèi)核、并行化服務(wù)網(wǎng)絡(luò)時延抖動大中斷處理不當(dāng)/調(diào)度延遲perf、cyclictest網(wǎng)卡中斷綁核、RT補丁4.5 一些容易忽略的“隱形”瓶頸除了上面這些明面上的瓶頸還有幾個“隱形”問題我覺得值得單獨拎出來說一下。第一個是調(diào)試串口的拖累。很多嵌入式工程師習(xí)慣在代碼里到處加printf打印但串口波特率通常只有115200約合每秒十幾KB。如果代碼里大量打印光串口輸出就能把CPU拖垮因為每輸出一個字符CPU都要等待串口FIFO刷新。我見過一個系統(tǒng)僅僅是因為調(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)的編譯選項是-O2但在嵌入式場景建議認(rèn)真試試-Os優(yōu)化體積。體積變小意味著緩存命中率提高、啟動時內(nèi)核加載時間變短有時候反而會比-O2更快。我在幾個項目里都驗證過-Os編譯的內(nèi)核在某些負載下性能比-O2更好還節(jié)省了Flash空間。第三個是電源管理策略?，F(xiàn)在的ARM SoC都支持動態(tài)調(diào)頻調(diào)壓DVFS。有時性能問題不是硬件不夠強而是CPU降頻了——可能是溫控策略太激進可能是電源管理框架把CPU調(diào)到了低功耗檔位。遇到性能不達預(yù)期、但硬件配置客觀夠用的場景一定要先檢查/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq確認(rèn)CPU是否跑在預(yù)期頻率上。5. 一個值得嘗試的調(diào)優(yōu)順序與檢查清單我在實際項目中總結(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看熱點如果進程卡住用strace抓系統(tǒng)調(diào)用。先排除應(yīng)用層的低級問題。內(nèi)核層定位應(yīng)用層沒問題再往內(nèi)核里挖用ftrace追蹤關(guān)鍵路徑用/proc/interrupts看中斷分布。針對定位結(jié)果做優(yōu)化每次只改一個變量改完重新量化對比確認(rèn)沒有引入新的問題。驗證長期穩(wěn)定性性能優(yōu)化完成不代表結(jié)束尤其是涉及內(nèi)存、實時性的改動要在目標(biāo)環(huán)境上持續(xù)運行幾天確認(rèn)無回歸。這個流程看起來簡單但很多人做不到原因就是“跳步”?？吹紺PU高就直接改代碼看到啟動慢就盲目裁剪內(nèi)核沒有先定位清楚最后往往是白忙活甚至越改越糟。另外一個常被忽略的點是優(yōu)化時要把“需求指標(biāo)”寫清楚?？蛻粽f“我要系統(tǒng)跑得快”這個描述沒有意義。你得追問您是要啟動快操作響應(yīng)快還是持續(xù)業(yè)務(wù)吞吐高每個指標(biāo)對應(yīng)的優(yōu)化路徑完全不同選錯方向就是在浪費團隊時間。我每次在項目啟動前都會把性能指標(biāo)寫成一個正式的表格發(fā)給客戶確認(rèn)簽字這樣后續(xù)優(yōu)化有據(jù)可依也避免做無用功。做嵌入式Linux這些年我最大的體會是性能問題從來不是單點問題而是一個系統(tǒng)性問題。CPU、內(nèi)存、I/O、啟動時間、實時性每個維度都像木桶的一塊板哪塊短了水都會漏。但好在大部分瓶頸都有跡可循解法也都是成熟的技術(shù)關(guān)鍵在于你有沒有耐心去測量、定位、驗證。還有一個心得優(yōu)化這件事越早介入成本越低。很多性能問題在設(shè)計階段就可以避免比如選型時評估內(nèi)存和存儲余量、設(shè)計時規(guī)劃好中斷優(yōu)先級、編碼時注意鎖粒度和系統(tǒng)調(diào)用頻率。等到設(shè)備量產(chǎn)了再出性能問題那種被客戶催著、被領(lǐng)導(dǎo)盯著的感覺真的希望你永遠不要體驗。