06丨效能分析思路都在這裡了

最後兩列中，前面是請求時間的 28ms，後面是後端響應時間的 28ms。

同時，我們再到 tomcat 上去看時間。

buffer used     3.00k of   8.00m  %used:   0.04

從上面的資料可以看到，key buffer size 就用到了 4%，顯然不用增加。

再比如，我們看到這樣的資料：

__tables_______________________ open 2000 of 2000 %cache: 100.00 opened 15.99m 4.1/s

這就明顯有問題了。配置值為 2000 的 open table cache，已經被佔滿了。顯然這裡需要分析。但是，看到狀態值達到配置值並不意味著我們需要趕緊加大配置值，而是要分析是否合理，再做相應的處理。比如說上面這個，table 確實開啟得多，但是如果我們再對應看下這一條。

slow 2 s        6.21m     1.6/s

你是不是覺得應該先去處理慢 sql 的問題了？

關於資料庫的我們就不舉更多的例子了。在這裡只是為了告訴你，在分析決策樹的建立過程中，有非常多的相互依賴關係。

然後我們再來看一下作業系統分析決策樹，我在這裡需要強調一下，作業系統的分析決策樹，不可以繞過。

如果你想到作業系統架構圖就頭大，那麼這時候應該覺得有了希望。那就是我覺得作業系統上的問題判斷是比較清晰的，所以基於此決策樹，每個人都可以做到對作業系統中效能問題的證據鏈查詢。

但是！對嘛，總得有個但是。

對作業系統的理解是個必然的前提。我看過很多人寫的作業系統效能分析方面的書籍或資料，發現大部分人把描述計數器的數值當成效能分析。

怎麼理解這句話呢？比如說

「cpu 使用率在 tps 上公升的過程中，從 10% 增加到 95%，超過了預期值。」「記憶體使用率達到 99%，所以是瓶頸點。」「i/o 使用率達到 100%。」等等。

像這樣的描述，在我的效能團隊中，一定會被罵回去重寫。我要這些描述有什麼用？我要的是為什麼達到了這樣的值，原因在哪？怎麼解決？

就像分析決策樹中所描述的那樣，效能工程師要做的是一步步地細化分析，給出最終的原因。

有人說，如果按這個路子，似乎作業系統的分析並不複雜嘛。大概三五個命令就可以跳到**層了。是的，對於操作來說，確實不多，但是對於判斷來說，那就複雜了。舉個例子來說明一下：

看到這樣的圖，你是不是有種手足無措的感覺？中斷能佔 40%，sy cpu 也能佔 40%。這系統還用幹業務的事嗎？全乾自己的事去了，可見作業系統有問題！你是不是要做這個判斷了？

而實際情況是，這個主機上只有乙個網絡卡佇列，而請求量又比較大。

所以要解決的是網絡卡佇列的問題，至於怎麼解決，那手段就多了。可以換個伺服器，可以多加幾個佇列，可以多接幾個節點…

以上只是給出幾個效能分析過程中常見的決策樹示例。在後續的分析過程例項中，我們將秉承著這種分析思路，一步步地走到瓶頸的面前。

場景的比對

為什麼要寫這一部分呢？因為我看到很多人對瓶頸的判斷，並不那麼精確，所以想寫一下場景比對的建議。

其實簡單來說，就一句話：當你覺得系統中哪個環節不行的時候，又沒能力分析它，你可以直接做該環節的增加。

舉例來，我們現在有乙個如下的架構：

可以得到樣的結果：

從 tp 曲線中，我們可以明顯看到系統是有瓶頸的，但是並不知道在**。鑑於系統架構如此簡單，我們索性直接在某環節上加上一台伺服器，變成這樣：

喲，沒好！

怎麼辦？再接著加其他節點，我加了更多的 jmeter 機器。

再來看下結果：

看到了吧，這就是我說的場景比對。

當我們不知道系統中哪個環節存在效能瓶頸時，對架構並不複雜的系統來說，可以使用這樣的手段，來做替換法，以快速定位問題。

總結在這一篇中，我說到了瓶頸的精準判斷、執行緒遞增的策略、效能衰減的過程、響應時間的拆分、構建分析決策樹以及場景的比對，這幾個環節，是效能分析過程中非常重要的環節。

從我的經驗上來說，這一篇文章可能是我工作十幾年的精華所在了。而這裡的每乙個環節，又有非常多的細分，特別是構建分析決策樹這一塊，它需要太多的架構知識、系統知識、資料庫知識等等。鑑於本文只是想起到乙個提綱挈領的作用，所以無法展開描述，希望在後續的篇幅中，我們盡量細緻拆解。

06丨 效能分析思路都在這裡了