借助或者研發好的分析工具對系統工程師的工作效率提升很重要

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

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

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

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

嵌入式平臺性能工作特點

嵌入式行業更關注系統性能工作

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

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

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

手機系統性能方面工作的關注點

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

1） 嵌入式行業關注點：

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

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

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

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

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

2）互聯網行業關注點：

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

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

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

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

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

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

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

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

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

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

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

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

systrace就是嵌入式系統性能分析中的倚天劍。

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

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

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

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

如果是offcputime耗時，那么需要看看是runable狀態耗時，還是D狀態耗時。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這方面解過的問題有：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我后來想了想，答復是：

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

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

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

這樣下來性能監控工作就會開發效率低了。

bcc工具最大好處是：

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

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

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

5》 其他的分析方法

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

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

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

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

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