一、上節回顧
上一節，我們一起學習了，應用程序監控的基本思路，先簡單回顧一下。應用程序的監控，可以分為指標監控和日志監控兩大塊。
指標監控，主要是對一定時間段內的性能指標進行測量，然后再通過時間序列的方式，進行處理、存儲和告警。
而日志監控，則可以提供更詳細的上下文信息，通常通過 ELK 技術棧，來進行收集、索引和圖形化展示。
在跨多個不同應用的復雜業務場景中，你還可以構建全鏈路跟蹤系統。這樣，你就可以動態跟蹤調用鏈中各個組件的性能，生成整個應用的調用拓撲圖，從而加快定位復雜應用的性能問題。
不過，如果你收到監控系統的告警，發現系統資源或者應用程序出現性能瓶頸，又該如何進一步分析它的根源呢？今天，我就分別從系統資源瓶頸和應用程序瓶頸這兩個角度，帶你一起來看
看，性能分析的一般步驟。
二、系統資源瓶頸
首先來看系統資源的瓶頸，這也是最為常見的性能問題。
在系統監控的綜合思路篇中，我曾經介紹過，系統資源的瓶頸，可以通過 USE 法，即使用率、飽和度以及錯誤數這三類指標來衡量。系統的資源，可以分為硬件資源和軟件資源兩類。
- 如 CPU、內存、磁盤和文件系統以及網絡等，都是最常見的硬件資源。
- 而文件描述符數、連接跟蹤數、套接字緩沖區大小等，則是典型的軟件資源。
這樣，在你收到監控系統告警時，就可以對照這些資源列表，再根據指標的不同來進行定位。
實際上，咱們專欄前四大模塊的核心，正是學會去分析這些資源瓶頸導致的性能問題。所以，當你碰到了系統資源的性能瓶頸時，前面模塊的所有思路、方法以及工具，都完全可以照用。
接下來，我就從 CPU 性能、內存性能、磁盤和文件系統 I/O 性能以及網絡性能等四個方面，帶你回顧一下它們的分析步驟
三、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 等工具，找出進程的熱點函數；甚至還可以使用動態追蹤的方法，來觀察進程的當前執行過程，直到確定瓶頸的根源。
四、內存性能分析
說完了 CPU 的性能分析，再來看看第二種系統資源，即內存。關於內存性能的分析方法，我在如何“快准狠”找到系統內存的問題中，也已經為你整理了一個快速分析的思路。
下面這張圖，就是一個迅速定位內存瓶頸的流程。我們可以通過 free 和 vmstat 輸出的性能指標，確認內存瓶頸；然后，再根據內存問題的類型，進一步分析內存的使用、分配、泄漏以及緩
存等，最后找出問題的來源。
同 CPU 性能一樣，很多內存的性能指標，也來源於 /proc 文件系統（比如/proc/meminfo、/proc/slabinfo 等），它們也都應該通過監控系統監控起來。這樣，當你收到
內存告警時，就可以從監控系統中，直接得到上圖中的各項性能指標，從而加快性能問題的定位過程。
比如說，當你收到內存不足的告警時，首先可以從監控系統中。找出占用內存最多的幾個進程。然后，再根據這些進程的內存占用歷史，觀察是否存在內存泄漏問題。確定出最可疑的進程后，
再登錄到進程所在的 Linux 服務器中，分析該進程的內存空間或者內存分配，最后弄清楚進程為什么會占用大量內存。
五、磁盤和文件系統 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 的原因。
六、網絡性能分析
最后的網絡性能，其實包含兩類資源，即網絡接口和內核資源。在網絡性能優化的幾個思路中，我也曾提到過，網絡性能的分析，要從 Linux 網絡協議棧的原理來切入。下面這張圖，就是
Linux 網絡協議棧的基本原理，包括應用層、套機字接口、傳輸層、網絡層以及鏈路層等。
而要分析網絡的性能，自然也是要從這幾個協議層入手，通過使用率、飽和度以及錯誤數這幾類性能指標，觀察是否存在性能問題。比如 ：
- 在鏈路層，可以從網絡接口的吞吐量、丟包、錯誤以及軟中斷和網絡功能卸載等角度分析；
- 在網絡層，可以從路由、分片、疊加網絡等角度進行分析；
- 在傳輸層，可以從 TCP、UDP 的協議原理出發，從連接數、吞吐量、延遲、重傳等角度進行分析；
- 在應用層，可以從應用層協議（如 HTTP 和 DNS）、請求數（QPS）、套接字緩存等角度進行分析。
同前面幾種資源類似，網絡的性能指標也都來源於內核，包括 /proc 文件系統（如/proc/net）、網絡接口以及 conntrack 等內核模塊。這些指標同樣需要被監控系統監控。這
樣，當你收到網絡告警時，就可以從監控系統中，查詢這些協議層的各項性能指標，從而更快定位出性能問題。
比如，當你收到網絡不通的告警時，就可以從監控系統中，查找各個協議層的丟包指標，確認丟包所在的協議層。然后，從監控系統的數據中，確認網絡帶寬、緩沖區、連接跟蹤數等軟硬件，
是否存在性能瓶頸。最后，再登錄到發生問題的 Linux 服務器中，借助 netstat、tcpdump、bcc 等工具，分析網絡的收發數據，並且結合內核中的網絡選項以及 TCP 等網絡協議的原理，找出問題的來源。
七、應用程序瓶頸
除了以上這些來自網絡資源的瓶頸外，還有很多瓶頸，其實直接來自應用程序。比如，最典型的應用程序性能問題，就是吞吐量（並發請求數）下降、錯誤率升高以及響應時間增大。
不過，在我看來，這些應用程序性能問題雖然各種各樣，但就其本質來源，實際上只有三種，也就是資源瓶頸、依賴服務瓶頸以及應用自身的瓶頸。
第一種資源瓶頸，其實還是指剛才提到的 CPU、內存、磁盤和文件系統 I/O、網絡以及內核資源等各類軟硬件資源出現了瓶頸，從而導致應用程序的運行受限。對於這種情況，我們就可以用前
面系統資源瓶頸模塊提到的各種方法來分析。
第二種依賴服務的瓶頸，也就是諸如數據庫、分布式緩存、中間件等應用程序，直接或者間接調用的服務出現了性能問題，從而導致應用程序的響應變慢，或者錯誤率升高。這說白了就是跨應
用的性能問題，使用全鏈路跟蹤系統，就可以幫你快速定位這類問題的根源。
最后一種，應用程序自身的性能問題，包括了多線程處理不當、死鎖、業務算法的復雜度過高等等。對於這類問題，在我們前面講過的應用程序指標監控以及日志監控中，觀察關鍵環節的耗時
和內部執行過程中的錯誤，就可以幫你縮小問題的范圍。
不過，由於這是應用程序內部的狀態，外部通常不能直接獲取詳細的性能數據，所以就需要應用程序在設計和開發時，就提供出這些指標，以便監控系統可以了解應用程序的內部運行狀態。
如果這些手段過后還是無法找出瓶頸，你還可以用系統資源模塊提到的各類進程分析工具，來進行分析定位。比如：
- 你可以用 strace，觀察系統調用；
- 使用 perf 和火焰圖，分析熱點函數；
- 甚至使用動態追蹤技術，來分析進程的執行狀態。
當然，系統資源和應用程序本來就是相互影響、相輔相成的一個整體。實際上，很多資源瓶頸，也是應用程序自身運行導致的。比如，進程的內存泄漏，會導致系統內存不足；進程過多的 I/O
請求，會拖慢整個系統的 I/O 請求等。
所以，很多情況下，資源瓶頸和應用自身瓶頸，其實都是同一個問題導致的，並不需要我們重復分析。
八、小結
今天，我帶你從系統資源瓶頸和應用程序瓶頸這兩個角度，梳理了性能問題分析的一般步驟。
從系統資源瓶頸的角度來說，USE 法是最為有效的方法，即從使用率、飽和度以及錯誤數這三個方面，來分析 CPU、內存、磁盤和文件系統 I/O、網絡以及內核資源限制等各類軟硬件資源。關
於這些資源的分析方法，我也帶你一起回顧了咱們專欄前面幾大模塊的分析套路。
從應用程序瓶頸的角度來說，我們可以把性能問題的來源，分為資源瓶頸、依賴服務瓶頸以及應用自身瓶頸這三類。
- 資源瓶頸跟系統資源瓶頸，本質是一樣的。
- 依賴服務瓶頸，你可以使用全鏈路跟蹤系統進行定位。
- 而應用自身的問題，你可以通過系統調用、熱點函數，或者應用自身的指標監控以及日志監控等，進行分析定位。
值得注意的是，雖然我把瓶頸分為了系統和應用兩個角度，但在實際運行時，這兩者往往是相輔相成、相互影響的。系統是應用的運行環境，系統的瓶頸會導致應用的性能下降；而應用的不合
理設計，也會引發系統資源的瓶頸。我們做性能分析，就是要結合應用程序和操作系統的原理，揪出引發問題的真凶。