借助或者研發(fā)好的分析工具對(duì)系統(tǒng)工程師的工作效率提升很重要

系統(tǒng)分析優(yōu)化工程師的工作職責(zé)跟app工程師有很大的不同，系統(tǒng)工程師需要具備cover住整個(gè)系統(tǒng)的能力。

現(xiàn)在的嵌入式系統(tǒng)比如android的代碼量有幾千萬(wàn)行，而且系統(tǒng)架構(gòu)搞得相當(dāng)龐大復(fù)雜。搞系統(tǒng)性能優(yōu)化的，嵌入式產(chǎn)品比如手機(jī)上隨意出現(xiàn)個(gè)性能問(wèn)題，可能都需要從fwk層（java代碼）一直搞到內(nèi)核底層，然后到存儲(chǔ)芯片層也需要熟悉（如果是搞存儲(chǔ)性能優(yōu)化的話）。

所以系統(tǒng)工程師，尤其是搞性能問(wèn)題解決優(yōu)化的，需要調(diào)研關(guān)注的代碼量相當(dāng)龐大，不止linux內(nèi)核。

所以搞系統(tǒng)性能工作的，往往需要借助或者研發(fā)一些高效的工具來(lái)提升工作效率。好的工具對(duì)于性能工程師的工作質(zhì)量提升是非常重要的。

嵌入式平臺(tái)性能工作特點(diǎn)

嵌入式行業(yè)更關(guān)注系統(tǒng)性能工作

嵌入式行業(yè)和互聯(lián)網(wǎng)行業(yè)在性能問(wèn)題解決優(yōu)化方面還是有著很大的不同，嵌入式行業(yè)比如手機(jī)產(chǎn)品，可以說(shuō)是比互聯(lián)網(wǎng)公司更關(guān)注性能問(wèn)題的解決優(yōu)化。

因?yàn)榛ヂ?lián)網(wǎng)公司出性能問(wèn)題了，可以搞內(nèi)存或者存儲(chǔ)設(shè)備擴(kuò)容，性能不好，再多加塊內(nèi)存條就解決了。

手機(jī)產(chǎn)品出廠后，內(nèi)存和存儲(chǔ)容量有限已經(jīng)定死了，但是隨著移動(dòng)互聯(lián)網(wǎng)時(shí)代的到來(lái)，各種app在不斷消耗爭(zhēng)用著手機(jī)的cpu/io/內(nèi)存資源，所以會(huì)產(chǎn)生很多性能問(wèn)題，會(huì)比互聯(lián)網(wǎng)公司更影響用戶體驗(yàn)。

手機(jī)系統(tǒng)性能方面工作的關(guān)注點(diǎn)

嵌入式行業(yè)和互聯(lián)網(wǎng)行業(yè)在性能問(wèn)題的關(guān)注點(diǎn)上也有不同。

1） 嵌入式行業(yè)關(guān)注點(diǎn)：

嵌入式行業(yè)，比如手機(jī)很關(guān)注特定進(jìn)程/線程（比如前臺(tái)app）的工作時(shí)延。性能問(wèn)題的解決和優(yōu)化，往往圍繞著如何減少特定進(jìn)程/線程的工作時(shí)延，使其運(yùn)行更快一些。這樣前臺(tái)app運(yùn)行快了，用戶操作手機(jī)時(shí)才不會(huì)感到有卡頓。

手機(jī)產(chǎn)品里面有相當(dāng)多的一部分性能工作是做這樣事情：

跑特定的性能測(cè)試程序（比如手機(jī)zip解壓縮或者io跑分），需要調(diào)查為啥測(cè)試機(jī)：高通某機(jī)型比對(duì)比機(jī)： mtk某機(jī)型慢了2秒，慢2秒是系統(tǒng)的哪部分原因?qū)е碌摹?/p>

如果是軟件原因，需要精確到具體是測(cè)試機(jī)和對(duì)比機(jī)的android系統(tǒng)（幾千萬(wàn)行代碼）的哪部分代碼差異導(dǎo)致的性能慢2秒。

如果是硬件原因，需要知道高通和mtk機(jī)型的哪部分硬件差異導(dǎo)致的性能慢2秒。

2）互聯(lián)網(wǎng)行業(yè)關(guān)注點(diǎn)：

互聯(lián)網(wǎng)行業(yè)，由于系統(tǒng)工程師的角色是優(yōu)化后臺(tái)服務(wù)器集群，所以搞性能工作，首要關(guān)注點(diǎn)是查找整個(gè)系統(tǒng)的性能瓶頸在哪里，提高整個(gè)系統(tǒng)運(yùn)行任務(wù)的吞吐量。優(yōu)化局部特定重要進(jìn)程工作時(shí)延方面，沒(méi)有嵌入式行業(yè)那么重要迫切。

嵌入式平臺(tái)性能工具運(yùn)用特點(diǎn)

由于上面講了手機(jī)和互聯(lián)網(wǎng)公司在性能工作方面的不同，手機(jī)性能優(yōu)化更關(guān)注前臺(tái)app的工作時(shí)延，所以嵌入式平臺(tái)上性能工具運(yùn)用也和互聯(lián)網(wǎng)公司有不同。

會(huì)linux下那些經(jīng)典性能排查工具僅僅是最基本的要求

一談到操作系統(tǒng)比如linux上的性能問(wèn)題分析，大家首先會(huì)想到要靈活運(yùn)用各種shell命令和開(kāi)源性能分析工具（比如free， top， df， vmstat， iostat， strace等）。

典型的就是那個(gè)美國(guó)性能大師brendangregg的那篇經(jīng)典博文《十分鐘幫你排查出性能問(wèn)題在哪里》中介紹的性能工具分析問(wèn)題思路。

但這些都是互聯(lián)網(wǎng)服務(wù)器行業(yè)的性能分析套路。手機(jī)產(chǎn)品上會(huì)運(yùn)用上面提的這些linux性能分析工具只是最基本的要求，僅僅會(huì)這些工具還不能滿足嵌入式產(chǎn)品的高性能質(zhì)量需求。

比如上文提的慢2秒，如果要調(diào)查其中原因，會(huì)上面提的基本性能排查工具還是查不出慢2秒的原因的。

嵌入式平臺(tái)（比如手機(jī)）性能工具運(yùn)用思路介紹

1 對(duì)于復(fù)現(xiàn)概率比較大或者必現(xiàn)的性能問(wèn)題的調(diào)查思路

比如針對(duì)前臺(tái)app卡頓或者操作性能慢這樣問(wèn)題的分析：

1》 首先會(huì)用到systrace排查性能問(wèn)題出現(xiàn)的大致范圍地方

systrace就是嵌入式系統(tǒng)性能分析中的倚天劍。

最常用的而且首要分析工具會(huì)是systrace，用它來(lái)做系統(tǒng)整體分析，也是對(duì)性能問(wèn)題的初步分析。

看看比如上面提的慢2秒這種性能問(wèn)題大致出現(xiàn)在什么地方，是出在測(cè)試機(jī)的on cputime還是off cputime耗時(shí)。

如果是oncputime耗時(shí)，需要關(guān)注是cpu頻率不夠，還是有后臺(tái)進(jìn)程干擾，或者是cpu調(diào)度問(wèn)題（都跑大核或者小核）造成的。

或者還需要關(guān)注測(cè)試程序本身，測(cè)試程序自身在很多關(guān)鍵地方代碼都加的有systrace tag，這樣比較容易看到是哪部分代碼導(dǎo)致的耗時(shí)。

如果是offcputime耗時(shí)，那么需要看看是runable狀態(tài)耗時(shí)，還是D狀態(tài)耗時(shí)。

runable耗時(shí)可能是cpu上排隊(duì)進(jìn)程太多導(dǎo)致，或者kswapd過(guò)于活躍（內(nèi)存原因）。

D狀態(tài)耗時(shí)可以通過(guò)進(jìn)入D狀態(tài)前的代碼位置，來(lái)判斷出是鎖同步，或者內(nèi)存/io原因?qū)е碌摹?/p>

這個(gè)也可以通過(guò)測(cè)試程序本身加的關(guān)鍵地方systrace tag，來(lái)看出offcputime耗時(shí)出現(xiàn)在程序的哪個(gè)代碼階段。

總之，上面說(shuō)的這些導(dǎo)致出性能問(wèn)題的因素都可以通過(guò)systrace看出來(lái)，通過(guò)systrace可以首先看出性能問(wèn)題的大致出現(xiàn)范圍。

2》 其次會(huì)用到simpleperf排查性能問(wèn)題出現(xiàn)原因?qū)?yīng)的詳細(xì)代碼

simpleperf則是性能分析中的屠龍刀。

光systrace工具還不夠的，systrace只能看到橫向性能分析結(jié)果。

比如通過(guò)對(duì)比測(cè)試機(jī)和對(duì)比機(jī)的systrace，看到了慢2秒的性能問(wèn)題是由于測(cè)試機(jī)頻繁調(diào)用了內(nèi)核里面misc_open函數(shù)，而導(dǎo)致耗時(shí)的。

這時(shí)需要查出為啥測(cè)試機(jī)會(huì)頻繁調(diào)用misc_open，這就要分析測(cè)試程序自身的業(yè)務(wù)邏輯代碼了。

如果分析測(cè)試程序涉及代碼量很龐大的話，手動(dòng)分析耗時(shí)，往往就要借助simpleperf（嵌入式平臺(tái)上的perf工具）進(jìn)行縱向性能分析了。

用simpleperf對(duì)測(cè)試程序的oncputime/offcputime進(jìn)行采樣，并且附帶采樣點(diǎn)的?；厮菪畔?，最后以火焰圖形式輸出，這樣很容易看到是哪部分上層業(yè)務(wù)代碼導(dǎo)致的底層內(nèi)核的misc_open被頻繁帶用。

3》 對(duì)于存儲(chǔ)性能問(wèn)題還會(huì)用到ftrace log分析

如果該性能問(wèn)題大概率是跟手機(jī)存儲(chǔ)io性能相關(guān)的，那么上面兩個(gè)排查方法還不一定能看出問(wèn)題真正原因所在。

因?yàn)榧词故莝impleperf，也只能看出測(cè)試程序涉及的各個(gè)地方代碼的整體耗時(shí)分布，類似火焰圖效果。但是某些熱點(diǎn)函數(shù)為什么這么耗時(shí)，還需要進(jìn)一步觀測(cè)它的參數(shù)變化。

如果是內(nèi)核io方面的熱點(diǎn)函數(shù)耗時(shí)，這個(gè)時(shí)候就需要開(kāi)啟內(nèi)核文件系統(tǒng)層，塊設(shè)備層相關(guān)的trace event跟蹤事件，同時(shí)需要對(duì)內(nèi)核存儲(chǔ)io棧代碼比較熟悉才行。

這樣會(huì)進(jìn)一步詳細(xì)看出類似上面的測(cè)試機(jī)慢2秒這種性能問(wèn)題原因。

這方面解過(guò)的問(wèn)題有：

1） 某測(cè)試機(jī)Q版本比P版本zip解壓縮耗時(shí)慢3秒，最后發(fā)現(xiàn)是Q版本的文件預(yù)讀窗口過(guò)小（和p版本相比）導(dǎo)致。

2） 某測(cè)試機(jī)連接u盤(pán)，首次播放u盤(pán)高清視頻卡住必現(xiàn)問(wèn)題，最后查到是塊設(shè)備層usbotg設(shè)備設(shè)置的參數(shù)不對(duì)，導(dǎo)致bio合并失敗引起的性能問(wèn)題。

4》 bcc工具也有很大的用武之地

在實(shí)際應(yīng)用上面提的工具解決性能問(wèn)題時(shí)，會(huì)發(fā)現(xiàn)還存在一些缺陷和改進(jìn)：

（1） 存儲(chǔ)IO跑分差這類性能問(wèn)題，用上面提的這些工具都不合適，還是用bcc工具最合適

因?yàn)閮?nèi)核io棧分文件系統(tǒng)層，塊設(shè)備層和存儲(chǔ)芯片層。每個(gè)層面代碼差異都會(huì)影響io跑分。

而實(shí)際測(cè)試場(chǎng)景下，經(jīng)常會(huì)有測(cè)試機(jī)和對(duì)比機(jī)的要么文件系統(tǒng)層不一樣，要么塊設(shè)備層代碼或者存儲(chǔ)芯片有差異，就是這些差異導(dǎo)致的測(cè)試機(jī)io跑分性能不如對(duì)比機(jī)。

所以針對(duì)這類性能問(wèn)題，最好用bcc工具，在具體跑分時(shí)，能夠?qū)ι厦鎯?nèi)核io棧的每個(gè)層面的處理耗時(shí)數(shù)據(jù)進(jìn)行歸納統(tǒng)計(jì)，能夠計(jì)算出每個(gè)層面的總耗時(shí)，平均耗時(shí)還有最大最小耗時(shí)等。

這樣便能看出來(lái)是文件系統(tǒng)層耗時(shí)引起的跑分性能差，還是塊設(shè)備層，或者存儲(chǔ)芯片層引起的。

systrace和ftrace log都做不到，perf工具只能在用戶態(tài)對(duì)數(shù)據(jù)做歸納處理，內(nèi)核態(tài)只是采樣或者trace event事件觸發(fā)收集性能信息直接匯報(bào)給用戶態(tài)。

io跑分需要在內(nèi)核態(tài)直接對(duì)性能數(shù)據(jù)做第一手的歸納處理，這個(gè)就是bcc工具最大用武之地了。

怎么用bcc工具處理io跑分類性能問(wèn)題的，可以看看我的那個(gè)存儲(chǔ)性能工具介紹文章。

（2） 對(duì)內(nèi)核熱點(diǎn)函數(shù)進(jìn)行長(zhǎng)時(shí)間的性能監(jiān)控時(shí)，perf工具會(huì)產(chǎn)生比較大的數(shù)據(jù)量和性能負(fù)荷，并且會(huì)有丟事件發(fā)生

這個(gè)是perf工具的自身缺陷問(wèn)題，內(nèi)核態(tài)不能做太多的數(shù)據(jù)過(guò)濾和歸納處理，只能采樣返回到用戶態(tài)做數(shù)據(jù)聚合處理。

自己在調(diào)查相機(jī)gpu內(nèi)存泄漏問(wèn)題時(shí)，用simpleperf監(jiān)控過(guò)內(nèi)核gpu內(nèi)存分配釋放事件活動(dòng)，內(nèi)核gpu分配/釋放事件是很頻繁的，每秒幾千次都有。

如果用perf監(jiān)控時(shí)間長(zhǎng)，產(chǎn)生的perf.data監(jiān)控log體積會(huì)特別大，達(dá)到1G多。并且還會(huì)有丟事件發(fā)生。

這個(gè)時(shí)候就需要有一種工具，能夠在內(nèi)核態(tài)對(duì)性能數(shù)據(jù)做些業(yè)務(wù)邏輯方面的過(guò)濾，或者直接內(nèi)核態(tài)對(duì)數(shù)據(jù)做歸納處理，最后返回到用戶態(tài)的只是處理過(guò)的精簡(jiǎn)版的結(jié)論數(shù)據(jù)。

這樣便會(huì)大大減輕性能監(jiān)控任務(wù)自身產(chǎn)生的負(fù)荷，降低對(duì)手機(jī)使用的影響。

這個(gè)工具目前最好的就是ebpf/bcc工具了。

（3）bcc工具還有更大的好處

之前我推廣我的存儲(chǔ)io跑分工具時(shí)，有人曾提疑問(wèn)，bcc工具操作比較麻煩，還得新增內(nèi)核配置項(xiàng)，還得望手機(jī)data分區(qū)push一整套200多M的bcc工具集。

為啥這么費(fèi)勁，為啥不直接在內(nèi)核io棧上加些trace event，不也能看出性能問(wèn)題出現(xiàn)原因嗎。

我后來(lái)想了想，答復(fù)是：

其實(shí)也可以不用bcc工具啊，如果直接加trace event，還是不行的，那么產(chǎn)生的數(shù)據(jù)量大，而且都是raw數(shù)據(jù)，沒(méi)有歸納處理。

最好用內(nèi)核模塊+kprobe接口/新增trace event事件，這樣自己在內(nèi)核模塊里面手動(dòng)加代碼，計(jì)算或者過(guò)濾監(jiān)控?cái)?shù)據(jù)的處理耗時(shí)，在io跑分前，加載該模塊開(kāi)啟監(jiān)控工作。

但是這樣有點(diǎn)問(wèn)題，針對(duì)io跑分做個(gè)性能監(jiān)控工具，然后有其他方面性能監(jiān)控需求時(shí)，可能需要再搞個(gè)另外的監(jiān)控程序。這樣時(shí)間長(zhǎng)了，性能監(jiān)控程序搞的種類多了，還得解決代碼復(fù)用性問(wèn)題，版本兼容工作。

這樣下來(lái)性能監(jiān)控工作就會(huì)開(kāi)發(fā)效率低了。

bcc工具最大好處是：

提供了一整套的性能監(jiān)控框架，可以使得很方便地快速定制和開(kāi)發(fā)自己的性能監(jiān)控工具，尤其是自己面臨很多方面的性能監(jiān)控工作需求時(shí)。

上面提的那些數(shù)據(jù)歸納處理過(guò)濾，其實(shí)bcc工具里面有現(xiàn)成的成熟接口可以調(diào)用。

有了bcc工具那個(gè)成熟的性能監(jiān)控框架，開(kāi)發(fā)者可以專注于自己的性能監(jiān)控業(yè)務(wù)邏輯開(kāi)發(fā)，不需要理會(huì)什么內(nèi)核代碼編寫(xiě)一些坑坑洼洼的工作。

5》 其他的分析方法

除了用上面性能分析工具外，還可以通過(guò)用戶反饋的log，來(lái)看性能問(wèn)題出現(xiàn)原因的。這些都放到偶現(xiàn)性能問(wèn)題解決里面來(lái)說(shuō)了。

2 偶現(xiàn)性能問(wèn)題的調(diào)查思路

1》利用Linux內(nèi)核的task delay數(shù)據(jù)統(tǒng)計(jì)可以看出用戶手機(jī)端的性能問(wèn)題是由于cpu，內(nèi)存還是io三大因素中哪個(gè)導(dǎo)致。

這個(gè)開(kāi)啟后對(duì)用戶的嵌入式產(chǎn)品產(chǎn)生的性能負(fù)荷很小的，不影響其運(yùn)行的，但只能看出大致性能原因在哪里。

2》在容易出性能問(wèn)題的層面加些性能打點(diǎn)log，進(jìn)一步輔助排查性能問(wèn)題出在哪里。前提是不影響嵌入式產(chǎn)品正常運(yùn)行。