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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果是軟件原因，需要精確到具體是測試機(jī)和對比機(jī)的android系統(tǒng)（幾千萬行代碼）的哪部分代碼差異導(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)化后臺服務(wù)器集群，所以搞性能工作，首要關(guān)注點(diǎn)是查找整個系統(tǒng)的性能瓶頸在哪里，提高整個系統(tǒng)運(yùn)行任務(wù)的吞吐量。優(yōu)化局部特定重要進(jìn)程工作時延方面，沒有嵌入式行業(yè)那么重要迫切。

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

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

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

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

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

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

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

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

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

比如針對前臺app卡頓或者操作性能慢這樣問題的分析：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3》 對于存儲性能問題還會用到ftrace log分析

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

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

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

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

這方面解過的問題有：

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

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

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

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

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

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

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

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

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

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

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

怎么用bcc工具處理io跑分類性能問題的，可以看看我的那個存儲性能工具介紹文章。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bcc工具最大好處是：

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

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

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

5》 其他的分析方法

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

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

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

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

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