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

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

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

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

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

嵌入式平臺性能工作特點

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

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

因為互聯網公司出性能問題了，可以搞內存或者存儲設備擴容，性能不好，再多加塊內存條就解決了。

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

手機系統(tǒng)性能方面工作的關注點

嵌入式行業(yè)和互聯網行業(yè)在性能問題的關注點上也有不同。

1） 嵌入式行業(yè)關注點：

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

手機產品里面有相當多的一部分性能工作是做這樣事情：

跑特定的性能測試程序（比如手機zip解壓縮或者io跑分），需要調查為啥測試機：高通某機型比對比機： mtk某機型慢了2秒，慢2秒是系統(tǒng)的哪部分原因導致的。

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

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

2）互聯網行業(yè)關注點：

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

嵌入式平臺性能工具運用特點

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

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

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

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

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

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

嵌入式平臺（比如手機）性能工具運用思路介紹

1 對于復現概率比較大或者必現的性能問題的調查思路

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

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

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

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

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

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

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

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

runable耗時可能是cpu上排隊進程太多導致，或者kswapd過于活躍（內存原因）。

D狀態(tài)耗時可以通過進入D狀態(tài)前的代碼位置，來判斷出是鎖同步，或者內存/io原因導致的。

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

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

2》 其次會用到simpleperf排查性能問題出現原因對應的詳細代碼

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

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

比如通過對比測試機和對比機的systrace，看到了慢2秒的性能問題是由于測試機頻繁調用了內核里面misc_open函數，而導致耗時的。

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

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

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

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

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

因為即使是simpleperf，也只能看出測試程序涉及的各個地方代碼的整體耗時分布，類似火焰圖效果。但是某些熱點函數為什么這么耗時，還需要進一步觀測它的參數變化。

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

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

這方面解過的問題有：

1） 某測試機Q版本比P版本zip解壓縮耗時慢3秒，最后發(fā)現是Q版本的文件預讀窗口過小（和p版本相比）導致。

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

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

在實際應用上面提的工具解決性能問題時，會發(fā)現還存在一些缺陷和改進：

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

因為內核io棧分文件系統(tǒng)層，塊設備層和存儲芯片層。每個層面代碼差異都會影響io跑分。

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

所以針對這類性能問題，最好用bcc工具，在具體跑分時，能夠對上面內核io棧的每個層面的處理耗時數據進行歸納統(tǒng)計，能夠計算出每個層面的總耗時，平均耗時還有最大最小耗時等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我后來想了想，答復是：

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

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

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

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

bcc工具最大好處是：

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

上面提的那些數據歸納處理過濾，其實bcc工具里面有現成的成熟接口可以調用。

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

5》 其他的分析方法

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

2 偶現性能問題的調查思路

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

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

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