如何回答性能優化的問題，才能打動阿裡面試官？

阿裡妹導讀：日常工作中，我們多少都會遇到應用的性能問題。在阿裡面試中，性能優化也是常被問到的題目，用來考察是否有實際的線上問題處理經驗。面對這類問題，阿裡工程師齊光給出了詳細流程。來阿裡面試前，先看看這篇文章哦。

性能問題和Bug不同，後者的分析和解決思路更清晰，很多時候從應用日志（文中的應用指分布式服務下的單個節點）即可直接找到問題根源，而性能問題，其排查思路更為複雜一些。

對應用進行性能優化，是一個系統性的工程，對工程師的技術廣度和技術深度都有所要求。一個簡單的應用，它不僅包含了應用代碼本身，還和容器（虛拟機）、作業系統、存儲、網絡、檔案系統等緊密相關，線上應用一旦出現了性能問題，需要我們從多方面去考慮。

與此同時，除了一些低級的代碼邏輯引發的性能問題外，很多性能問題隐藏的較深，排查起來會比較困難，需要我們對應用的各個子子產品、應用所使用的架構群組件的原理有所了解，同時掌握一定的性能優化工具和經驗。

本文總結了我們在進行性能優化時常用的一些工具及技巧，目的是希望通過一個全面的視角，去感覺性能優化的整體脈絡。本文主要分為下面三個部分：

1. 第一部分會介紹性能優化的一些背景知識。
2. 第二部分會介紹性能優化的通用流程以及常見的一些誤區。
3. 第三部分會從系統層和業務層的角度，介紹高效的性能問題定位工具和高頻性能瓶頸點分布。

本文中提到的線程、堆、垃圾回收等名詞，如無特别說明，指的是 Java 應用中的相關概念。

1.性能優化的背景

前面提到過，應用出現性能問題和應用存在缺陷是不一樣的，後者大多數是由于代碼的品質問題導緻，會導緻應用功能性的缺失或出現風險，一經發現，會被及時修複。而性能問題，可能是由多方面的因素共同作用的結果：代碼品質一般、業務發展太快、應用架構設計不合理等，這些問題處理起來一般耗時較長、分析鍊路複雜，大家都不願意幹，是以可能會被一些臨時性的補救手段所掩蓋，如：系統水位高或者單機的線程池隊列爆炸，那就叢集擴容增加機器；記憶體占用高/高峰時段 OOM，那就重新開機分分鐘解決......

臨時性的補救措施隻是在給應用埋雷，同時也隻能解決部分問題。譬如，在很多場景下，加機器也并不能解決應用的性能問題，如對時延比較敏感的一些應用必須把單機的性能優化到極緻，與此同時，加機器這種方式也造成了資源的浪費，長期來看是得不償失的。對應用進行合理的性能優化，可在應用穩定性、成本核算獲得很大的收益。

上面我們闡述了進行性能優化的必要性。假設現在我們的應用已經有了性能問題（eg. CPU 水位比較高），準備開始進行優化工作了，在這個過程中，潛在的痛點會有哪些呢？下面列出一些較為常見的：

1. 對性能優化的流程不是很清晰。初步定為一個疑似瓶頸點後，就興高采烈地吭哧吭哧開始幹，最終解決的問題其實隻是一個淺層次的性能瓶頸，真實的問題的根源并未觸達；
2. 對性能瓶頸點的分析思路不是很清晰。CPU、網絡、記憶體......這麼多的性能名額，我到底該關注什麼，應該從哪一塊兒開始入手？
3. 對性能優化的工具不了解。遇到問題後，不清楚該用哪個工具，不知道通過工具得到的名額代表什麼。

2.性能優化的流程

在性能優化這個領域，并沒有一個嚴格的流程定義，但是對于絕大多數的優化場景，我們可以将其過程抽象為下面四個步驟。

1. 準備階段：主要工作是是通過性能測試，了解應用的概況、瓶頸的大概方向，明确優化目标；
2. 分析階段：通過各種工具或手段，初步定位性能瓶頸點；
3. 調優階段：根據定位到的瓶頸點，進行應用性能調優；
4. 測試階段：讓調優過的應用進行性能測試，與準備階段的各項名額進行對比，觀測其是否符合預期，如果瓶頸點沒有消除或者性能名額不符合預期，則重複步驟2和3。

下圖即為上述四個階段的簡要流程。

2.1 通用流程詳解

在上述通用流程的四個步驟當中，步驟2和3我們會在接下來兩個部分重點進行介紹。首先我們來看一下，在準備階段和測試階段，我們需要做一些什麼。

| 2.1.1 準備階段

準備階段是非常關鍵的一步，不能省略。

首先，需要對我們進行調優的對象進行詳盡的了解，所謂知己知彼，百戰不殆。

1. 對性能問題進行粗略評估，過濾一些因為低級的業務邏輯導緻的性能問題。譬如，線上應用日志級别不合理，可能會在大流量時導緻 CPU 和磁盤的負載飙高，這種情況調整日志級别即可；
2. 了解應用的的總體架構，比如應用的外部依賴和核心接口有哪些，使用了哪些元件和架構，哪些接口、子產品的使用率較高，上下遊的資料鍊路是怎麼樣的等；
3. 了解應用對應的伺服器資訊，如伺服器所在的叢集資訊、伺服器的 CPU/記憶體資訊、安裝的 Linux 版本資訊、伺服器是容器還是虛拟機、所在主控端混部後是否對目前應用有幹擾等；

其次，我們需要擷取基準資料，然後結合基準資料和目前的一些業務名額，确定此次性能優化的最終目标。

1. 使用基準測試工具擷取系統細粒度名額。可以使用若幹 Linux 基準測試工具（eg. jmeter、ab、loadrunnerwrk、wrk等），得到檔案系統、磁盤 I/O、網絡等的性能報告。除此之外，類似 GC、Web 伺服器、網卡流量等資訊，如有必要也是需要了解記錄的；
2. 通過壓測工具或者壓測平台（如果有的話），對應用進行壓力測試，擷取目前應用的宏觀業務名額，譬如：響應時間、吞吐量、TPS、QPS、消費速率（對于有 MQ 的應用）等。壓力測試也可以省略，可以結合目前的實際業務和過往的監控資料，去統計目前的一些核心業務名額，如午高峰的服務 TPS。

| 2.1.2 測試階段

進入到這一階段，說明我們已經初步确定了應用性能瓶頸的所在，而且已經進行初步的調優了。檢測我們調優是否有效的方式，就是在仿真的條件下，對應用進行壓力測試。注意：由于 Java 有 JIT（just-in-time compilation）過程，是以壓力測試時可能需要進行前期預熱。

如果壓力測試的結果符合了預期的調優目标，或者與基準資料相比，有很大的改善，則我們可以繼續通過工具定位下一個瓶頸點，否則，則需要暫時排除這個瓶頸點，繼續尋找下一個變量。

2.2 注意事項

在進行性能優化時，了解下面這些注意事項可以讓我們少走一些彎路。

1. 性能瓶頸點通常呈現 2/8 分布，即80%的性能問題通常是由20%的性能瓶頸點導緻的，2/8 原則也意味着并不是所有的性能問題都值得去優化；
2. 性能優化是一個漸進、疊代的過程，需要逐漸、動态地進行。記錄基準後，每次改變一個變量，引入多個變量會給我們的觀測、優化過程造成幹擾；
3. 不要過度追求應用的單機性能，如果單機表現良好，則應該從系統架構的角度去思考; 不要過度追求單一次元上的極緻優化，如過度追求 CPU 的性能而忽略了記憶體方面的瓶頸；
4. 選擇合适的性能優化工具，可以使得性能優化取得事半功倍的效果；
5. 整個應用的優化，應該與線上系統隔離，新的代碼上線應該有降級方案。

3.瓶頸點分析工具箱

性能優化其實就是找出應用存在性能瓶頸點，然後設法通過一些調優手段去緩解。性能瓶頸點的定位是較困難的，快速、直接地定位到瓶頸點，需要具備下面兩個條件：

1. 恰到好處的工具；
2. 一定的性能優化經驗。

工欲善其事，必先利其器，我們該如何選擇合适的工具呢？不同的優化場景下，又該選擇那些工具呢？

首選，我們來看一下大名鼎鼎的「性能工具(Linux Performance Tools-full)圖」，想必很多工程師都知道，它出自系統性能專家 Brendan Gregg。該圖從 Linux 核心的各個子系統出發，列出了我們在對各個子系統進行性能分析時，可使用的工具，涵蓋了監測、分析、調優等性能優化的方方面面。除了這張全景圖之外，Brendan Gregg 還單獨提供了基準測試工具(Linux Performance Benchmark Tools)圖、性能監測工具(Linux Performance Observability Tools)圖等，更詳細的内容請參考 Brendan Gregg 的網站說明。

圖檔來源：

http://www.brendangregg.com/linuxperf.html?spm=ata.13261165.0.0.34646b44KX9rGc

上面這張圖非常經典，是我們做性能優化時非常好的參考資料，但事實上，我們在實際運用的時候，會發現可能它并不是最合适的，原因主要有下面兩點：

1）對分析經驗要求較高。上面這張圖其實是從 Linux 系統資源的角度去觀測性能名額的，這要求我們對 Linux 各個子系統的功能、原理要有所了解。舉例：遇到性能問題了，我們不會拿每個子系統下的工具都去試一遍，大多數情況是：我們懷疑某個子系統有問題，然後根據這張圖上列舉的工具，去觀測或者驗證我們的猜想，這無疑拔高了對性能優化經驗的要求；

2）适用性和完整性不是很好。我們在分析性能問題時，從系統底層自底向上地分析是較低效的，大多數時候，從應用層面去分析會更加有效。性能工具(Linux Performance Tools-full)圖隻是從系統層一個角度給出了工具集，如果從應用層開始分析，我們可以使用哪些工具？哪些點是我們首先需要關注的？

鑒于上面若幹痛點，下面給出了一張更為實用的「性能優化工具圖譜」，該圖分别從系統層、應用層（含元件層）的角度出發，列舉了我們在分析性能問題時首先需要關注的各項名額（其中?标注的是最需要關注的），這些點是最有可能出現性能瓶頸的地方。需要注意的是，一些低頻的名額或工具，在圖中并沒有列出來，如 CPU 中斷、索引節點使用、I/O事件跟蹤等，這些低頻點的排查思路較複雜，一般遇到的機會也不多，在這裡我們聚焦最常見的一些就可以了。

對比上面的性能工具(Linux Performance Tools-full)圖，下圖的優勢在于：把具體的工具同性能名額結合了起來，同時從不同的層次去描述了性能瓶頸點的分布，實用性和可操作性更強一些。系統層的工具分為CPU、記憶體、磁盤（含檔案系統）、網絡四個部分，工具集同性能工具(Linux Performance Tools-full)圖中的工具基本一緻。元件層和應用層中的工具構成為：JDK 提供的一些工具 + Trace 工具 + dump 分析工具 + Profiling 工具等。

這裡就不具體介紹這些工具的具體用法了，我們可以使用 man 指令得到工具詳盡的使用說明，除此之外，還有另外一個查詢指令手冊的方法：info。info 可以了解為 man 的詳細版本，如果 man 的輸出不太好了解，可以去參考 info 文檔，指令太多，記不住也沒必要記住。

上面這張圖該如何使用？

首先，雖然從系統、元件、應用兩個三個角度去描述瓶頸點的分布，但在實際運作時，這三者往往是相輔相成、互相影響的。系統是為應用提供了運作時環境，性能問題的本質就是系統資源達到了使用的上限，反映在應用層，就是應用/元件的各項名額開始下降；而應用/元件的不合理使用和設計，也會加速系統資源的耗盡。是以，分析瓶頸點時，需要我們結合從不同角度分析出的結果，抽出共性，得到最終的結論。

其次，建議先從應用層入手，分析圖中标注的高頻名額，抓出最重要的、最可疑的、最有可能導緻性能的點，得到初步的結論後，再去系統層進行驗證。這樣做的好處是：很多性能瓶頸點展現在系統層，會是多變量呈現的，譬如，應用層的垃圾回收（GC）名額出現了異常，通過 JDK 自帶的工具很容易觀測到，但是展現在系統層上，會發現系統目前的 CPU 使用率、記憶體名額都不太正常，這就給我們的分析思路帶來了困擾。

最後，如果瓶頸點在應用層和系統層均呈現出多變量分布，建議此時使用 ZProfiler、JProfiler 等工具對應用進行 Profiling，擷取應用的綜合性能資訊（注：Profiling 指的是在應用運作時，通過事件（Event-based）、統計抽樣（Sampling Statistical）或植入附加指令（Byte-Code instrumentation）等方法，收集應用運作時的資訊，來研究應用行為的動态分析方法）。譬如，可以對 CPU 進行抽樣統計，結合各種符号表資訊，得到一段時間内應用内的代碼熱點。

下面介紹在不同的分析層次，我們需要關注的核心性能名額，同時，也會介紹如何初步根據這些名額，判斷系統或應用是否存在性能瓶頸點，至于瓶頸點的确認、瓶頸點的成因、調優手段，将會在下一部分展開。

3.1 CPU&&線程

和 CPU 相關的名額主要有以下幾個。常用的工具有 top、 ps、uptime、 vmstat、 pidstat等。

1. CPU使用率（CPU Utilization）
2. CPU 平均負載（Load Average）
3. 上下文切換次數（Context Switch）

top - 12:20:57 up 25 days, 20:49, 2 users, load average: 0.93, 0.97, 0.79

Tasks: 51 total, 1 running, 50 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.6 us, 1.8 sy, 0.0 ni, 89.1 id, 0.1 wa, 0.0 hi, 0.1 si, 7.3 st

KiB Mem : 8388608 total, 476436 free, 5903224 used, 2008948 buff/cache

KiB Swap: 0 total, 0 free, 0 used. 0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

119680 admin 20 0 600908 72332 5768 S 2.3 0.9 52:32.61 obproxy

65877 root 20 0 93528 4936 2328 S 1.3 0.1 449:03.61 alisentry_cli

第一行顯示的内容：目前時間、系統運作時間以及正在登入使用者數。load average 後的三個數字，依次表示過去 1 分鐘、5 分鐘、15 分鐘的平均負載（Load Average）。平均負載是指機關時間内，系統處于可運作狀态（正在使用 CPU 或者正在等待 CPU 的程序，R 狀态）和不可中斷狀态（D 狀态）的平均程序數，也就是平均活躍程序數，CPU 平均負載和 CPU 使用率并沒有直接關系。

第三行的内容表示 CPU 使用率，每一列的含義可以使用 man 檢視。CPU 使用率展現了機關時間内 CPU 使用情況的統計，以百分比的方式展示。計算方式為：CPU 使用率 = 1 - （CPU 空閑時間）/ CPU 總的時間。需要注意的是，通過性能分析工具得到的 CPU 的使用率其實是某個采樣時間内的 CPU 平均值。注：top 工具顯示的的 CPU 使用率是把所有 CPU 核的數值加起來的，即 8 核 CPU 的使用率最大可以到達800%（可以用 htop 等更新一些的工具代替 top）。

使用 vmstat 指令，可以檢視到「上下文切換次數」這個名額，如下表所示，每隔1秒輸出1組資料：

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 0 0 504804 0 1967508 0 0 644 33377 0 1 2 2 88 0 9

上表的 cs（context switch） 就是每秒上下文切換的次數，按照不同場景，CPU 上下文切換還可以分為中斷上下文切換、線程上下文切換和程序上下文切換三種，但是無論是哪一種，過多的上下文切換，都會把 CPU 時間消耗在寄存器、核心棧以及虛拟記憶體等資料的儲存和恢複上，進而縮短程序真正運作的時間，導緻系統的整體性能大幅下降。vmstat 的輸出中 us、sy 分别使用者态和核心态的 CPU 使用率，這兩個值也非常具有參考意義。

vmstat 的輸隻給出了系統總體的上下文切換情況，要想檢視每個程序的上下文切換詳情（如自願和非自願切換），需要使用 pidstat，該指令還可以檢視某個程序使用者态和核心态的 CPU 使用率。

CPU 相關名額異常的分析思路是什麼？

1）CPU 使用率：如果我們觀察某段時間系統或應用程序的 CPU使用率一直很高（單個 core 超過80%），那麼就值得我們警惕了。我們可以多次使用 jstack 指令 dump 應用線程棧檢視熱點代碼，非 Java 應用可以直接使用 perf 進行 CPU 采采樣，離線分析采樣資料後得到 CPU 執行熱點（Java 應用需要符号表進行堆棧資訊映射，不能直接使用 perf得到結果）。

2）CPU 平均負載：平均負載高于 CPU 數量 70%，意味着系統存在瓶頸點，造成負載升高的原因有很多，在這裡就不展開了。需要注意的是，通過監控系統監測平均負載的變化趨勢，更容易定位問題，有時候大檔案的加載等，也會導緻平均負載瞬時升高。如果 1 分鐘/5 分鐘/15 分鐘的三個值相差不大，那說明系統負載很平穩，則不用關注，如果這三個值逐漸降低，說明負載在漸漸升高，需要關注整體性能；

3）CPU 上下文切換：上下文切換這個名額，并沒有經驗值可推薦（幾十到幾萬都有可能），這個名額值取決于系統本身的 CPU 性能，以及目前應用工作的情況。但是，如果系統或者應用的上下文切換次數出現數量級的增長，就有很大機率說明存在性能問題，如非自願上下切換大幅度上升，說明有太多的線程在競争 CPU。

上面這三個名額是密切相關的，如頻繁的 CPU 上下文切換，可能會導緻平均負載升高。如何根據這三者之間的關系進行應用調優，将在下一部分介紹。

CPU 上的的一些異動，通常也可以從線程上觀測到，但需要注意的是，線程問題并不完全和 CPU 相關。與線程相關的名額，主要有下面幾個（均都可以通過 JDK 自帶的 jstack 工具直接或間接得到）：

1. 應用中的總的線程數；
2. 應用中各個線程狀态的分布；
3. 線程鎖的使用情況，如死鎖、鎖分布等；

關于線程，可關注的異常有：

1）線程總數是否過多。過多的線程，展現在 CPU 上就是導緻頻繁的上下文切換，同時線程過多也會消耗記憶體，線程總數大小和應用本身和機器配置相關；

2）線程的狀态是否異常。觀察 WAITING/BLOCKED 線程是否過多（線程數設定過多或鎖競争劇烈），結合應用内部鎖使用的情況綜合分析；

3）結合 CPU 使用率，觀察是否存在大量消耗 CPU 的線程。

3.2 記憶體&&堆

和記憶體相關的名額主要有以下幾個，常用的分析工具有：top、free、vmstat、pidstat 以及 JDK 自帶的一些工具。

1. 系統記憶體的使用情況，包括剩餘記憶體、已用記憶體、可用記憶體、緩存/緩沖區；
2. 程序（含 Java 程序）的虛拟記憶體、常駐記憶體、共享記憶體；
3. 程序的缺頁異常數，包含主缺頁異常和次缺頁異常；
4. Swap 換入和換出的記憶體大小、Swap 參數配置；
5. JVM 堆的配置設定，JVM 啟動參數；
6. JVM 堆的回收，GC 情況。

使用 free 可以檢視系統記憶體的使用情況和 Swap 分區的使用情況，top 工具可以具體到每個程序，如我們可以用使用 top 工具檢視 Java 程序的常駐記憶體大小（RES），這兩個工具結合起來，可用覆寫大多數記憶體名額。下面是使用 free指令的輸出：

$free -h

total        used        free      shared  buff/cache   available           

Mem: 125G 6.8G 54G 2.5M 64G 118G

Swap: 2.0G 305M 1.7G

上述輸出各列的具體含義在這裡不在贅述，也比較容易了解。重點介紹下 swap 和 buff/cache 這兩個名額。

Swap 的作用是把一個本地檔案或者一塊磁盤空間作為記憶體來使用，包括換出和換入兩個過程。Swap 需要讀寫磁盤，是以性能不是很高，事實上，包括 ElasticSearch 、Hadoop 在内絕大部分 Java 應用都建議關掉 Swap，這是因為記憶體的成本一直在降低，同時這也和 JVM 的垃圾回收過程有關：JVM在 GC 的時候會周遊所有用到的堆的記憶體，如果這部分記憶體被 Swap 出去了，周遊的時候就會有磁盤 I/O 産生。Swap 分區的升高一般和磁盤的使用強相關，具體分析時，需要結合緩存使用情況、swappiness 門檻值以及匿名頁和檔案頁的活躍情況綜合分析。

buff/cache 是緩存和緩沖區的大小。緩存（cache）：是從磁盤讀取的檔案的或者向磁盤寫檔案時的臨時存儲資料，面向檔案。使用 cachestat 可以檢視整個系統緩存的讀寫命中情況，使用 cachetop 可以觀察每個程序緩存的讀寫命中情況。緩沖區（buffer）是寫入磁盤資料或從磁盤直接讀取的資料的臨時存儲，面向塊裝置。free 指令的輸出中，這兩個名額是加在一起的，使用 vmstat 指令可以區分緩存和緩沖區，還可以看到 Swap 分區換入和換出的記憶體大小。

了解到常見的記憶體名額後，常見的記憶體問題又有哪些？總結如下：

1. 系統剩餘記憶體/可用不足（某個程序占用太多、系統本身記憶體不足），記憶體溢出；
2. 記憶體回收異常：記憶體洩漏（程序在一段時間内記憶體使用持續走高）、GC 頻率異常；
3. 緩存使用過大（大檔案讀取或寫入）、緩存命中率不高；
4. 缺頁異常過多（頻繁的 I/O 讀）；
5. Swap 分區使用異常（使用過大）；

記憶體相關名額異常後，分析思路是怎麼樣的？

1. 使用 free/top 檢視記憶體的全局使用情況，如系統記憶體的使用、Swap 分區記憶體使用、緩存/緩沖區占用情況等，初步判斷記憶體問題存在的方向：程序記憶體、緩存/緩沖區、Swap 分區；
2. 觀察一段時間記憶體的使用趨勢。如通過 vmstat 觀察記憶體使用是否一直在增長；通過 jmap 定時統計對象記憶體分布情況，判斷是否存在記憶體洩漏，通過 cachetop 指令，定位緩沖區升高的根源等；
3. 根據記憶體問題的類型，結合應用本身，進行詳細分析。

舉例：使用 free 發現緩存/緩沖區占用不大，排除緩存/緩沖區對記憶體的影響後 -> 使用 vmstat 或者 sar 觀察一下各個程序記憶體使用變化趨勢 -> 發現某個程序的記憶體時候用持續走高 -> 如果是 Java 應用，可以使用 jmap / VisualVM / heap dump 分析等工具觀察對象記憶體的配置設定，或者通過 jstat 觀察 GC 後的應用記憶體變化 -> 結合業務場景，定位為記憶體洩漏/GC參數配置不合理/業務代碼異常等。

3.3 磁盤&&檔案

在分析和磁盤相關的問題時，通常是将其和檔案系統同時考慮的，下面不再區分。和磁盤/檔案系統相關的名額主要有以下幾個，常用的觀測工具為 iostat和 pidstat，前者适用于整個系統，後者可觀察具體程序的 I/O。

1. 磁盤 I/O 使用率：是指磁盤處理 I/O 的時間百分比；
2. 磁盤吞吐量：是指每秒的 I/O 請求大小，機關為 KB;
3. I/O 響應時間，是指 I/O 請求從發出到收到響應的間隔，包含在隊列中的等待時間和實際處理時間；
4. IOPS（Input/Output Per Second）：每秒的 I/O 請求數；
5. I/O 等待隊列大小，指的是平均 I/O 隊列長度，隊列長度越短越好；

使用 iostat 的輸出界面如下：

$iostat -dx

Linux 3.10.0-327.ali2010.alios7.x86_64 (loginhost2.alipay.em14) 10/20/2019 x86_64 (32 CPU)

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util

sda 0.01 15.49 0.05 8.21 3.10 240.49 58.92 0.04 4.38 2.39 4.39 0.09 0.07

上圖中 %util ，即為磁盤 I/O 使用率，同 CPU 使用率一樣，這個值也可能超過 100%（存在并行 I/O）；rkB/s 和 wkB/s分别表示每秒從磁盤讀取和寫入的資料量，即吞吐量，機關為 KB；磁盤 I/O處理時間的名額為 r_await 和 w_await 分别表示讀/寫請求處理完成的響應時間，svctm 表示處理 I/O 所需要的平均時間，該名額已被廢棄，無實際意義。r/s + w/s 為 IOPS 名額，分别表示每秒發送給磁盤的讀請求數和寫請求數；aqu-sz 表示等待隊列的長度。

pidstat 的輸出大部分和 iostat 類似，差別在于它可以實時檢視每個程序的 I/O 情況。

如何判斷磁盤的名額出現了異常？

1. 當磁盤 I/O 使用率長時間超過 80%，或者響應時間過大（對于 SSD，從 0.0x 毫秒到 1.x 毫秒不等，機械磁盤一般為5ms~10ms），通常意味着磁盤 I/O 存在性能瓶頸；
2. 如果 %util 很大，而 rkB/s 和 wkB/s 很小，一般是因為存在較多的磁盤随機讀寫，最好把随機讀寫優化成順序讀寫，（可以通過 strace 或者 blktrace 觀察 I/O 是否連續判斷是否是順序的讀寫行為，随機讀寫應可關注 IOPS 名額，順序讀寫可關注吞吐量名額）；
3. 如果 avgqu-sz 比較大，說明有很多 I/O 請求在隊列中等待。一般來說，如果單塊磁盤的隊列長度持續超過2，一般認為該磁盤存在 I/O 性能問題。

3.4 網絡

網絡這個概念涵蓋的範圍較廣，在應用層、傳輸層、網絡層、網絡接口層都有不同的名額去衡量。這裡我們讨論的「網絡」，特指應用層的網絡，通常使用的名額如下:

1. 網絡帶寬：表示鍊路的最大傳輸速率；
2. 網絡吞吐：表示機關時間内成功傳輸的資料量大小；
3. 網絡延時：表示從網絡請求發出後直到收到遠端響應，所需要的時間；
4. 網絡連接配接數和錯誤數；

一般來說，應用層的網絡瓶頸有如下幾類：

1. 叢集或機器所在的機房的網絡帶寬飽和，影響應用 QPS/TPS 的提升；
2. 網絡吞吐出現異常，如接口存在大量的資料傳輸，造成帶寬占用過高；
3. 網絡連接配接出現異常或錯誤；
4. 網絡出現分區。

帶寬和網絡吞吐這兩個名額，一般我們會關注整個應用的，通過監控系統可直接得到，如果一段時間内出現了明顯的名額上升，說明存在網絡性能瓶頸。對于單機，可以使用 sar 得到網絡接口、程序的網絡吞吐。

使用 ping 或者 hping3 可以得到是否出現網絡分區、網絡具體時延。對于應用，我們更關注整個鍊路的時延，可以通過中間件埋點後輸出的 trace 日志得到鍊路上各個環節的時延資訊。

使用 netstat、ss 和 sar 可以擷取網絡連接配接數或網絡錯誤數。過多網絡連結造成的開銷是很大的，一是會占用檔案描述符，二是會占用緩存，是以系統可以支撐的網絡連結數是有限的。

3.5 工具總結

可以看到的是，在分析 CPU、記憶體、磁盤等的性能名額時，有幾種工具是高頻出現的，如 top、vmstat、pidstat，這裡稍微總結一下:

1. CPU：top、vmstat、pidstat、sar、perf、jstack、jstat；
2. 記憶體：top、free、vmstat、cachetop、cachestat、sar、jmap；
3. 磁盤：top、iostat、vmstat、pidstat、du/df；
4. 網絡：netstat、sar、dstat、tcpdump；
5. 應用：profiler、dump分析。

上述的很多工具，大部分是用于檢視系統層名額的，在應用層，除了有 JDK 提供的一系列工具，一些商用的産品如 gceasy.io（分析 GC 日志）、fastthread.io（分析線程 dump 日志）也是不錯的。

排查 Java 應用的線上異常或者分析應用代碼瓶頸，可以使用阿裡開源的 Arthas ，這個工具非常強大，下面簡單介紹下。

Arthas 主要面向線上應用實時診斷，解決的是類似「線上應用異常了，需要線上進行分析和定位」的問題，當然，Arthas 提供的一些方法調用追蹤工具，對我們排查諸如「慢查詢」等問題，也是非常有幫助的。Arthas 提供的主要功能有：

1. 擷取線程統計，如線程持有的鎖統計、CPU 使用率統計等；
2. 類加載資訊、動态類加載、方法加載資訊；
3. 調用棧追蹤，調用耗時統計；
4. 方法調用參數、結果檢測；
5. 系統配置、應用配置資訊；
6. 反編譯加載類；
7. ....

需要注意的是，性能工具隻是解決性能問題的手段，我們了解常用工具的一般用法即可，不要在工具學習上投入過多精力。

在通過工具得到異常名額，初步定位瓶頸點後，如何進一步進行确認和調優？這裡将給出常見的一些調優分析思路，内容會按照CPU、記憶體、網絡、磁盤等進行組織。詳情見：

https://developer.aliyun.com/article/727625?spm=5176.8068049.0.0.7f0d6d19WJXuiS

原文釋出時間為：2019-11-21

作者： 齊光

本文來自雲栖社群合作夥伴“

阿裡技術

”，了解相關資訊可以關注“

”。