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

1、上節回顧

上一節，咱們一塊兒學習了，應用程序監控的基本思路，先簡單回顧一下。應用程序的監控，能夠分爲指標監控和日誌監控兩大塊。

指標監控，主要是對必定時間段內的性能指標進行測量，而後再經過時間序列的方式，進行處理、存儲和告警。

而日誌監控，則能夠提供更詳細的上下文信息，一般經過 ELK 技術棧，來進行收集、索引和圖形化展現。

在跨多個不一樣應用的複雜業務場景中，你還能夠構建全鏈路跟蹤系統。這樣，你就能夠動態跟蹤調用鏈中各個組件的性能，生成整個應用的調用拓撲圖，從而加快定位複雜應用的性能問題。

不過，若是你收到監控系統的告警，發現系統資源或者應用程序出現性能瓶頸，又該如何進一步分析它的根源呢？今天，我就分別從系統資源瓶頸和應用程序瓶頸這兩個角度，帶你一塊兒來看
看，性能分析的通常步驟。

2、系統資源瓶頸

首先來看系統資源的瓶頸，這也是最爲常見的性能問題。

在系統監控的綜合思路篇中，我曾經介紹過，系統資源的瓶頸，能夠經過 USE 法，即使用率、飽和度以及錯誤數這三類指標來衡量。系統的資源，能夠分爲硬件資源和軟件資源兩類。

1. 如 CPU、內存、磁盤和文件系統以及網絡等，都是最多見的硬件資源。
2. 而文件描述符數、鏈接跟蹤數、套接字緩衝區大小等，則是典型的軟件資源。

這樣，在你收到監控系統告警時，就能夠對照這些資源列表，再根據指標的不一樣來進行定位。

實際上，我們專欄前四大模塊的核心，正是學會去分析這些資源瓶頸致使的性能問題。因此，當你碰到了系統資源的性能瓶頸時，前面模塊的全部思路、方法以及工具，都徹底能夠照用。

接下來，我就從 CPU 性能、內存性能、磁盤和文件系統 I/O 性能以及網絡性能等四個方面，帶你回顧一下它們的分析步驟

3、CPU 性能分析

第一種最多見的系統資源是 CPU。關於 CPU 的性能分析方法，我在如何迅速分析出系統 CPU的瓶頸中，已經爲你整理了一個迅速分析 CPU 性能瓶頸的思路。

還記得這張圖嗎？利用 top、vmstat、pidstat、strace 以及 perf 等幾個最多見的工具，獲取CPU 性能指標後，再結合進程與 CPU 的工做原理，就能夠迅速定位出 CPU 性能瓶頸的來源。

實際上，top、pidstat、vmstat 這類工具所彙報的 CPU 性能指標，都源自 /proc 文件系統（好比 /proc/loadavg、/proc/stat、/proc/softirqs 等）。這些指標，都應該經過監控系統監控起
來。雖然並不是全部指標都須要報警，但這些指標卻能夠加快性能問題的定位分析。

好比說，當你收到系統的用戶 CPU 使用率太高告警時，從監控系統中直接查詢到，致使 CPU 使用率太高的進程；而後再登陸到進程所在的 Linux 服務器中，分析該進程的行爲。

你可使用 strace，查看進程的系統調用匯總；也可使用 perf 等工具，找出進程的熱點函數；甚至還可使用動態追蹤的方法，來觀察進程的當前執行過程，直到肯定瓶頸的根源。

4、內存性能分析

說完了 CPU 的性能分析，再來看看第二種系統資源，即內存。關於內存性能的分析方法，我在如何「快準狠」找到系統內存的問題中，也已經爲你整理了一個快速分析的思路。

下面這張圖，就是一個迅速定位內存瓶頸的流程。咱們能夠經過 free 和 vmstat 輸出的性能指標，確認內存瓶頸；而後，再根據內存問題的類型，進一步分析內存的使用、分配、泄漏以及緩
存等，最後找出問題的來源。

同 CPU 性能同樣，不少內存的性能指標，也來源於 /proc 文件系統（好比/proc/meminfo、/proc/slabinfo 等），它們也都應該經過監控系統監控起來。這樣，當你收到
內存告警時，就能夠從監控系統中，直接獲得上圖中的各項性能指標，從而加快性能問題的定位過程。

好比說，當你收到內存不足的告警時，首先能夠從監控系統中。找出佔用內存最多的幾個進程。而後，再根據這些進程的內存佔用歷史，觀察是否存在內存泄漏問題。肯定出最可疑的進程後，
再登陸到進程所在的 Linux 服務器中，分析該進程的內存空間或者內存分配，最後弄清楚進程爲何會佔用大量內存。

5、磁盤和文件系統 I/O 性能分析

接下來，咱們再來看第三種系統資源，即磁盤和文件系統的 I/O。關於磁盤和文件系統的 I/O 性能分析方法，我在如何迅速分析出系統 I/O 的瓶頸中也已經爲你整理了一個快速分析的思路。

咱們來看下面這張圖。當你使用 iostat ，發現磁盤 I/O 存在性能瓶頸（好比 I/O 使用率太高、響應時間過長或者等待隊列長度忽然增大等）後，能夠再經過 pidstat、 vmstat 等，確認 I/O
的來源。接着，再根據來源的不一樣，進一步分析文件系統和磁盤的使用率、緩存以及進程的 I/O等，從而揪出 I/O 問題的真兇

同 CPU 和內存性能相似，不少磁盤和文件系統的性能指標，也來源於 /proc 和 /sys 文件系統（好比 /proc/diskstats、/sys/block/sda/stat 等）。天然，它們也應該經過監控系統監控起
來。這樣，當你收到 I/O 性能告警時，就能夠從監控系統中，直接獲得上圖中的各項性能指標，從而加快性能定位的過程。

好比說，當你發現某塊磁盤的 I/O 使用率爲 100% 時，首先能夠從監控系統中。找出 I/O 最多的進程。而後，再登陸到進程所在的 Linux 服務器中，藉助 strace、lsof、perf 等工具，分析該進
程的 I/O 行爲。最後，再結合應用程序的原理，找出大量 I/O 的緣由。

6、網絡性能分析

最後的網絡性能，其實包含兩類資源，即網絡接口和內核資源。在網絡性能優化的幾個思路中，我也曾提到過，網絡性能的分析，要從 Linux 網絡協議棧的原理來切入。下面這張圖，就是
Linux 網絡協議棧的基本原理，包括應用層、套機字接口、傳輸層、網絡層以及鏈路層等。

而要分析網絡的性能，天然也是要從這幾個協議層入手，經過使用率、飽和度以及錯誤數這幾類性能指標，觀察是否存在性能問題。好比 ：

1. 在鏈路層，能夠從網絡接口的吞吐量、丟包、錯誤以及軟中斷和網絡功能卸載等角度分析；
2. 在網絡層，能夠從路由、分片、疊加網絡等角度進行分析；
3. 在傳輸層，能夠從 TCP、UDP 的協議原理出發，從鏈接數、吞吐量、延遲、重傳等角度進行分析；
4. 在應用層，能夠從應用層協議（如 HTTP 和 DNS）、請求數（QPS）、套接字緩存等角度進行分析。

同前面幾種資源相似，網絡的性能指標也都來源於內核，包括 /proc 文件系統（如/proc/net）、網絡接口以及 conntrack 等內核模塊。這些指標一樣須要被監控系統監控。這
樣，當你收到網絡告警時，就能夠從監控系統中，查詢這些協議層的各項性能指標，從而更快定位出性能問題。

好比，當你收到網絡不通的告警時，就能夠從監控系統中，查找各個協議層的丟包指標，確認丟包所在的協議層。而後，從監控系統的數據中，確認網絡帶寬、緩衝區、鏈接跟蹤數等軟硬件，
是否存在性能瓶頸。最後，再登陸到發生問題的 Linux 服務器中，藉助 netstat、tcpdump、bcc 等工具，分析網絡的收發數據，而且結合內核中的網絡選項以及 TCP 等網絡協議的原理，找出問題的來源。

7、應用程序瓶頸

除了以上這些來自網絡資源的瓶頸外，還有不少瓶頸，其實直接來自應用程序。好比，最典型的應用程序性能問題，就是吞吐量（併發請求數）降低、錯誤率升高以及響應時間增大。

不過，在我看來，這些應用程序性能問題雖然各類各樣，但就其本質來源，實際上只有三種，也就是資源瓶頸、依賴服務瓶頸以及應用自身的瓶頸。

第一種資源瓶頸，其實仍是指剛纔提到的 CPU、內存、磁盤和文件系統 I/O、網絡以及內核資源等各種軟硬件資源出現了瓶頸，從而致使應用程序的運行受限。對於這種狀況，咱們就能夠用前
面系統資源瓶頸模塊提到的各類方法來分析。

第二種依賴服務的瓶頸，也就是諸如數據庫、分佈式緩存、中間件等應用程序，直接或者間接調用的服務出現了性能問題，從而致使應用程序的響應變慢，或者錯誤率升高。這說白了就是跨應
用的性能問題，使用全鏈路跟蹤系統，就能夠幫你快速定位這類問題的根源。

最後一種，應用程序自身的性能問題，包括了多線程處理不當、死鎖、業務算法的複雜度太高等等。對於這類問題，在咱們前面講過的應用程序指標監控以及日誌監控中，觀察關鍵環節的耗時
和內部執行過程當中的錯誤，就能夠幫你縮小問題的範圍。

不過，因爲這是應用程序內部的狀態，外部一般不能直接獲取詳細的性能數據，因此就須要應用程序在設計和開發時，就提供出這些指標，以便監控系統能夠了解應用程序的內部運行狀態。

若是這些手段事後仍是沒法找出瓶頸，你還能夠用系統資源模塊提到的各種進程分析工具，來進行分析定位。好比：

1. 你能夠用 strace，觀察系統調用；
2. 使用 perf 和火焰圖，分析熱點函數；
3. 甚至使用動態追蹤技術，來分析進程的執行狀態。

固然，系統資源和應用程序原本就是相互影響、相輔相成的一個總體。實際上，不少資源瓶頸，也是應用程序自身運行致使的。好比，進程的內存泄漏，會致使系統內存不足；進程過多的 I/O
請求，會拖慢整個系統的 I/O 請求等。

因此，不少狀況下，資源瓶頸和應用自身瓶頸，其實都是同一個問題致使的，並不須要咱們重複分析。

8、小結

今天，我帶你從系統資源瓶頸和應用程序瓶頸這兩個角度，梳理了性能問題分析的通常步驟。

從系統資源瓶頸的角度來講，USE 法是最爲有效的方法，即從使用率、飽和度以及錯誤數這三個方面，來分析 CPU、內存、磁盤和文件系統 I/O、網絡以及內核資源限制等各種軟硬件資源。關
於這些資源的分析方法，我也帶你一塊兒回顧了我們專欄前面幾大模塊的分析套路。

從應用程序瓶頸的角度來講，咱們能夠把性能問題的來源，分爲資源瓶頸、依賴服務瓶頸以及應用自身瓶頸這三類。

1. 資源瓶頸跟系統資源瓶頸，本質是同樣的。
2. 依賴服務瓶頸，你可使用全鏈路跟蹤系統進行定位。
3. 而應用自身的問題，你能夠經過系統調用、熱點函數，或者應用自身的指標監控以及日誌監控等，進行分析定位。

值得注意的是，雖然我把瓶頸分爲了系統和應用兩個角度，但在實際運行時，這二者每每是相輔相成、相互影響的。系統是應用的運行環境，系統的瓶頸會致使應用的性能降低；而應用的不合理設計，也會引起系統資源的瓶頸。咱們作性能分析，就是要結合應用程序和操做系統的原理，揪出引起問題的真兇。