Linux性能優化實戰學習筆記：第五十八講

1、上節回顧

專欄更新至今，我們專欄最後一部分——綜合案例模塊也要告一段落了。很高興看到你沒有掉隊，仍然在積極學習思考、實踐操做，並熱情地分享你在實際環境中，遇到過的各類性能問題的
分析思路以及優化方法。

今天是性能優化答疑的第六期。照例，我從綜合案例模塊的留言中，摘出了一些典型問題，做爲今天的答疑內容，集中回覆。爲了便於你學習理解，它們並非嚴格按照文章順序排列的。每一個
問題，我都附上了留言區提問的截屏。若是你須要回顧內容原文，能夠掃描每一個問題右下方的二維碼查看。

2、問題 1：容器冷啓動性能分析

一、問題

二、解答：

在爲何應用容器化後，啓動慢了不少中，咱們一塊兒分析了容器化所致使的應用程序啓動緩慢的問題。簡單回顧一下當時的案例，Docker 經過 Cgroups 給容器設置了內存限制，可是容器並未
意識到 ，因此仍是分配了過多內存，致使被系統 OOM 殺死。

這個案例的根源實際上比較簡單，Tony 同窗就此提了一個更深刻的問題。

咱們知道，容器爲應用程序的管理帶來了巨大的便捷，諸如 Serverless（只關注應用的運行，而無需關注服務器）、FaaS（Function as a Service）等新型的軟件架構，也都基於容器技術來構
建。不過，雖然容器啓動已經很快了，但在啓動新容器，也就是冷啓動的時候，啓動時間相對於應用程序的性能要求來講，仍是過長了。

那麼，應該怎麼來分析和優化冷啓動的性能呢？

這個問題最核心的一點，其實就是要弄清楚，啓動時間到底都花在哪兒了。通常來講，一個Serverless 服務的啓動，包括：

• 事件觸發（好比收到新的 HTTP 調用請求）；
• 資源調度；
• 鏡像拉取；
• 網絡配置
• 啓動應用等幾個過程。

這幾個過程所消耗的時間，均可以經過鏈路跟蹤的方式來監控，進而就能夠定位出耗時最多的一個或者多個流程。

緊接着，針對耗時最多的流程，咱們能夠經過應用程序監控或者動態追蹤的方法，定位出耗時最多的字模塊，這樣也就找出了要優化的瓶頸點。

好比，鏡像拉取流程，能夠經過緩存熱點鏡像來減小鏡像拉取時間；網絡配置流程，能夠經過網絡資源預分配進行加速；而資源調度和容器啓動，也能夠經過複用預先建立好的容器來進行優化。

3、perf probe 失敗怎麼辦？

一、問題

二、解答：

在內核線程 CPU 利用率太高的案例中，咱們一塊兒經過 perf 和火焰圖工具，生成了內核熱點函數調用棧的動態矢量圖，並定位出性能問題發生時，執行最爲頻繁的內核函數。

因爲案例分析中，咱們主要關注的是 CPU 的繁忙狀況，因此這時候生成的火焰圖，被稱爲 on-CPU 火焰圖。事實上，除此以外，還有 off-CPU、內存等不一樣的火焰圖，分別表示 CPU 的阻塞和
內存的分配釋放狀況。

因此，李逍遙同窗提了出一個很好的問題：一樣都是火焰圖，CPU 火焰圖和內存火焰圖，在生成數據時到底有什麼不一樣？

這個問題，剛好問到了最核心的點上。CPU 火焰圖和內存火焰圖，最大的差異其實就是數據來源的不一樣，也就是函數堆棧不一樣，而火焰圖的格式仍是徹底同樣的。

• 對 CPU 火焰圖來講，採集的數據主要是消耗 CPU 的函數；
• 而對內存火焰圖來講，採集的數據主要是內存分配、釋放、換頁等內存管理函數。

舉個例子，咱們在使用 perf record 時，默認的採集事件 cpu-cycles ，就是採集 on-CPU 數據，而生成的火焰圖就是 CPU 火焰圖。經過 perf record -e page-fault 將採集事件換成 page-fault
後，就能夠採集內存缺頁的數據，生成的火焰圖天然就成了內存火焰圖。

4、perf probe 失敗怎麼辦？

一、問題

二、解答：

在動態追蹤怎麼用中，咱們一塊兒經過幾個案例，學習了 perf、bcc 等動態追蹤工具的使用方法。

這些動態追蹤方法，能夠在不修改代碼、不重啓服務的狀況下，讓你動態瞭解應用程序或內核的執行過程。這對於排查狀況複雜、難復現的問題尤爲有效。

在使用動態追蹤工具時，因爲十六進制格式的函數地址並不容易理解，就須要咱們藉助調試信息，將它們轉換爲更直觀的函數名。對於內核來講，我已經屢次提到過，須要安裝 debuginfo。
不過，針對應用程序又該怎麼辦呢？

這裏其實有兩種方法。

第一種方法，假如應用程序提供了調試信息軟件包，那你就能夠直接安裝來使用。好比，對於咱們案例中的 bash 來講，就能夠經過下面的命令，來安裝它的調試信息：

# Ubuntu
apt-get install -y bash-dbgsym

# Centos
debuginfo-install bash

第二種方法，使用源碼從新編譯應用程序，並開啓編譯器的調試信息開關，好比能夠爲 gcc 增長-g 選項。

5、問題 4：RED 法監控微服務應用

一、問題

二、解答：

在系統監控的綜合思路中，我爲你介紹了監控系統資源性能時經常使用的 USE 法。USE 法把系統資源的性能指標，簡化成了三類：使用率、飽和度以及錯誤數。三者之中任一類別的指標太高時，都
表明相應的系統資源可能有性能瓶頸。

不過，對應用程序的監控來講，這些指標顯然就不合適了。由於應用程序的核心指標，是請求數、錯誤數和響應時間。那該怎麼辦呢？這其實，正是 Adam 同窗在留言中提到的 RED 方法。

RED 方法，是 Weave Cloud 在監控微服務性能時，結合 Prometheus 監控，所提出的一種監控思路——即對微服務來講，監控它們的請求數（Rate）、錯誤數（Errors）以及響應時間

（Duration）。因此，RED 方法適用於微服務應用的監控，而 USE 方法適用於系統資源的監控。

6、問題 5：深刻內核的方法

一、問題

 

 

二、解答：

在定位性能問題時，咱們經過 perf、ebpf、systemtap 等各類方法排查時，極可能會發現，問題的熱點在內核中的某個函數中。而青石和 xfan 的問題，就是如何去了解、深刻 Linux 內核的原
理，特別是想弄清楚，性能工具展現的內核函數究竟是什麼含義。

其實，要了解內核函數的含義，最好的方法，就是去查詢所用內核版本的源代碼。這裏，我推薦https://elixir.bootlin.com 這個網站。使用方法也很簡單，從左邊選擇內核版本，再經過內核函數
名稱去搜索就能夠了。

之因此推薦這個網站，是由於它不只可讓你快速搜索函數定位，還爲全部的函數、變量、宏定義等，都提供了快速跳轉的功能。這樣，當你看到不明白的函數或變量時，點擊就能夠跳轉到相
應的定義處。

此外，對於 eBPF 來講，除了能夠經過內核源碼來了解，我更推薦你從 BPF Compiler Collection(BCC) 這個項目開始。BCC 提供了不少短小的示例，能夠幫你快速瞭解 eBPF 的工做原理，並熟
悉 eBPF 程序的開發思路。瞭解這些基本的用法後，再去深刻 eBPF 的內部，就會輕鬆不少。

今天我主要回答這些問題，同時也歡迎你繼續在留言區寫下疑問和感想，我會持續不斷地在留言區跟你交流。但願藉助每一次的答疑和交流，能夠和你一塊兒，

把專欄中的各類知識轉化爲你的能力。