性能分析

1.前提
性能分析的前提除了需要豐富的性能測試監(jiān)控（如PTS（Performance Testing Service）自身的客戶側(cè)監(jiān)控、基礎(chǔ)類監(jiān)控-阿里云監(jiān)控、應(yīng)用類 監(jiān)控-ARMS監(jiān)控等），還需要具備相關(guān)的技術(shù)知識（包括但不限于：操作系統(tǒng)、中間件、數(shù)據(jù)庫、開發(fā)等）。

2.流程

• a : 跟進以往經(jīng)驗，出現(xiàn)TPS不達標的情況，優(yōu)先查看硬件資源使用率，可以很快速直觀的看到資源使用情況來深入分析，例如應(yīng)用服務(wù)器 和 數(shù)據(jù)庫服務(wù)器 的CPU，Memory，Disk I/O，Network I/O，如果是某個硬件指標有問題，需要深入的進行分析。
  監(jiān)控工具：阿里云、亞馬遜云 或 自己搭建的grafana等平臺均可以監(jiān)控。

• b: 如果說上面步驟資源消耗正常，沒有出現(xiàn)飆高的情況，可以先從網(wǎng)絡(luò)接入層開始進行分析。很多情況下壓測流量并沒有完全進入到后端（服務(wù)端），在網(wǎng)絡(luò)接入層（云化的架構(gòu)，例如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就會出現(xiàn)由于各種規(guī)格（帶寬、最大連接數(shù)、新建連接數(shù)等）限制或者因為壓測的某些特征符合DDoS(Distributed Denial of Service分布式阻斷服務(wù)）的行為而觸發(fā)了防護策略導(dǎo)致壓測結(jié)果達不到預(yù)期。

• c: 接著看關(guān)鍵指標是否滿足要求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務(wù)器端問題可能性比較大，也有可能是客戶端問題（這種情況非常?。?。

• d: 如果硬件指標都沒有問題，需要查看中間件相關(guān)指標，例如：線程池、連接池、GC等，如果是這些指標問題，需要深入的分析。

• e: 如果中間件相關(guān)指標沒問題，需要查看數(shù)據(jù)庫相關(guān)指標，例如：慢查SQL、命中率、鎖、參數(shù)設(shè)置。

• f: 如果以上指標都正常，應(yīng)用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。
  

  image.png

3.可能瓶頸點

• 硬件、規(guī)格上的瓶頸
  一般指的是CPU、內(nèi)存、磁盤I/O方面的問題，分為服務(wù)器硬件瓶頸、網(wǎng)絡(luò)瓶頸（對局域網(wǎng)可以不考慮）。

• 中間件上的性能瓶頸
  一般指的是應(yīng)用服務(wù)器、web服務(wù)器等應(yīng)用軟件，還包括數(shù)據(jù)庫系統(tǒng)。 例如：中間件weblogic平臺上配置的JDBC連接池的參數(shù)設(shè)置不合理，造成的瓶頸。

• 應(yīng)用程序上的性能瓶頸
  一般指的是開發(fā)人員開發(fā)出來的應(yīng)用程序。 例如，JVM參數(shù)不合理，容器配置不合理，慢SQL（可使用阿里云APM類產(chǎn)品如ARMS協(xié)助定位），數(shù)據(jù)庫設(shè)計不合理，程序架構(gòu)規(guī)劃不合理，程序本身設(shè)計有問題（串行處理、請求的處理線程不夠、無緩沖、無緩存、生產(chǎn)者和消費者不協(xié)調(diào)等），造成系統(tǒng)在大量用戶訪問時性能低下而造成的瓶頸。

• 操作系統(tǒng)上的性能瓶頸
  一般指的是windows、UNIX、Linux等操作系統(tǒng)。 例如，在進行性能測試，出現(xiàn)物理內(nèi)存不足時，虛擬內(nèi)存設(shè)置也不合理，虛擬內(nèi)存的交換效率就會大大降低，從而導(dǎo)致行為的響應(yīng)時間大大增加，這時認為操作系統(tǒng)上出現(xiàn)性能瓶頸。

• 網(wǎng)絡(luò)設(shè)備上的性能瓶頸
  一般指的是防火墻、動態(tài)負載均衡器、交換機等設(shè)備。當前更多的云化服務(wù)架構(gòu)使用的網(wǎng)絡(luò)接入產(chǎn)品：包括但不限于SLB、WAF、高防IP、CDN、全站加速等等。 例如，在動態(tài)負載均衡器上設(shè)置了動態(tài)分發(fā)負載的機制，當發(fā)現(xiàn)某個應(yīng)用服務(wù)器上的硬件資源已經(jīng)到達極限時，動態(tài)負載均衡器將后續(xù)的交易請求發(fā)送到其他負載較輕的應(yīng)用服務(wù)器上。在測試時發(fā)現(xiàn)，動態(tài)負載均衡器沒有起到相應(yīng)的作用，這時可以認為網(wǎng)絡(luò)瓶頸。

4.方法

• CPU
  CPU資源利用率很高的話，需要看CPU消耗User、Sys、Wait哪種狀態(tài)。

  • 如果CPU User非常高，需要查看消耗在哪個進程，可以用top（linux）命令看出，接著用top –H –p <pid>看哪個線程消耗資源高。如果是Java應(yīng)用，就可以用jstack看出此線程正在執(zhí)行的堆棧，看資源消耗在哪個方法上，查看源代碼就知道問題所在；如果是c++應(yīng)用，可以用gprof性能工具進行分析。
  • 如果CPU Sys非常高，可以用strace（linux）看系統(tǒng)調(diào)用的資源消耗及時間。
  • 如果CPU Wait非常高，考慮磁盤讀寫了，可以通過減少日志輸出、異步或換速度快的硬盤。

• Memory
  操作系統(tǒng)為了最大化利用內(nèi)存，一般都設(shè)置大量的cache，因此，內(nèi)存利用率高達99%并不是問題，內(nèi)存的問題主要看某個進程占用的內(nèi)存是否非常大以及是否有大量的swap（虛擬內(nèi)存交換）。

• 磁盤I/O
  磁盤I/O一個最顯著的指標是繁忙率，可以通過減少日志輸出、異步或換速度快的硬盤來降低繁忙率。

• 網(wǎng)絡(luò)I/O
  網(wǎng)絡(luò)I/O主要考慮傳輸內(nèi)容大小，不能超過硬件網(wǎng)絡(luò)傳輸?shù)淖畲笾?0%，可以通過壓縮減少內(nèi)容大小、在本地設(shè)置緩存以及分多次傳輸?shù)炔僮魈岣呔W(wǎng)絡(luò)I/O性能。

• 內(nèi)核參數(shù)
  內(nèi)核參數(shù)一般都有默認值，這些內(nèi)核參數(shù)默認值對于一般系統(tǒng)沒問題，但是對于壓力測試來說，可能運行的參數(shù)將會超過內(nèi)核參數(shù)，導(dǎo)致系統(tǒng)出現(xiàn)問題，可以用sysctl來查看及修改。

• JVM
  JVM主要分析GC/FULL GC是否頻繁，以及垃圾回收的時間，可以用jstat命令來查看，對于每個代大小以及GC頻繁，通過jmap將內(nèi)存轉(zhuǎn)儲，再借助工具HeapAnalyzer來分析哪地方占用的內(nèi)存較高以及是否有內(nèi)存泄漏可能。簡單點可以使用APM工具，例如阿里云ARMS。

• 線程池
  如果線程不夠用，可以通過參數(shù)調(diào)整，增加線程；對于線程池中的線程設(shè)置比較大的情況，還是不夠用可能的原因是：某個線程被阻塞來不及釋放，可能在等鎖、方法耗時較長、數(shù)據(jù)庫等待時間很長等原因?qū)е?，需要進一步分析才能定位。

• JDBC連接池
  連接池不夠用的情況下，可以通過參數(shù)進行調(diào)整增加；但是對于數(shù)據(jù)庫本身處理很慢的情況下，調(diào)整沒有多大的效果，需要查看數(shù)據(jù)庫方面以及因代碼導(dǎo)致連接未釋放的原因。

• SQL
  SQL效率低下也是導(dǎo)致性能差的一個非常重要的原因，可以通過查看執(zhí)行計劃看SQL慢在哪里，一般情況，SQL效率低下原因主要有：

  
  
  SQL問題列表

調(diào)優(yōu)

1.調(diào)優(yōu)步驟

• 確定問題
  應(yīng)用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對于發(fā)現(xiàn)瓶頸的模塊，應(yīng)該首先檢查一下代碼。
  數(shù)據(jù)庫配置：經(jīng)常引起整個系統(tǒng)運行緩慢，一些諸如大型數(shù)據(jù)庫都是需要DBA進行正確的參數(shù)調(diào)整才能投產(chǎn)的。
  操作系統(tǒng)配置：不合理就可能引起系統(tǒng)瓶頸。
  硬件設(shè)置：硬盤速度、內(nèi)存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。
  網(wǎng)絡(luò)：網(wǎng)絡(luò)負載過重導(dǎo)致網(wǎng)絡(luò)沖突和網(wǎng)絡(luò)延遲。

• 分析問題
  當確定了問題之后，我們要明確這個問題影響的是響應(yīng)時間吞吐量，還是其他問題？
  是多數(shù)用戶還是少數(shù)用戶遇到了問題？如果是少數(shù)用戶，這幾個用戶與其它用戶的操作有什么不同？
  系統(tǒng)資源監(jiān)控的結(jié)果是否正常？CPU的使用是否到達極限？I/O情況如何？
  問題是否集中在某一類模塊中？
  是客戶端還是服務(wù)器出現(xiàn)問題？ 系統(tǒng)硬件配置是否夠用？
  實際負載是否超過了系統(tǒng)的負載能力？ 是否未對系統(tǒng)進行優(yōu)化？
  通過這些分析及一些與系統(tǒng)相關(guān)的問題，可以對系統(tǒng)瓶頸有更深入的了解，進而分析出真正的原因。

• 確定調(diào)整目標和解決方案
  高系統(tǒng)吞吐量，縮短響應(yīng)時間，更好地支持并發(fā)。

• 測試解決方案
  對通過解決方案調(diào)優(yōu)后的系統(tǒng)進行基準測試。（基準測試是指通過設(shè)計科學的測試方法、測試工具和測試系統(tǒng)，實現(xiàn)對一類測試對象的某項性能指標進行定量的和可對比的測試）。

• 分析調(diào)優(yōu)結(jié)果
  系統(tǒng)調(diào)優(yōu)是否達到或者超出了預(yù)定目標；系統(tǒng)是整體性能得到了改善，還是以系統(tǒng)某部分性能來解決其他問題；調(diào)優(yōu)是否可以結(jié)束了。 最后，如果達到了預(yù)期目標，調(diào)優(yōu)工作可以先告一段落。

2. 調(diào)優(yōu)注意事項

• 在應(yīng)用系統(tǒng)的設(shè)計開發(fā)過程中，應(yīng)始終把性能放在考慮的范圍內(nèi)，將性能測試常態(tài)化，日?；膬?nèi)網(wǎng)的性能測試+定期的真實環(huán)境的業(yè)務(wù)性能測試，PTS都可以支持。
• 確定清晰明確的性能目標是關(guān)鍵，進而將目標轉(zhuǎn)化為PTS中的壓測場景并設(shè)置好需要的目標量級，然后視情況選擇并發(fā)、TPS模式，自動遞增/手工調(diào)速的組合進行流量控制。
• 必須保證調(diào)優(yōu)后的程序運行正確。
• 系統(tǒng)的性能更大程度上取決于良好的設(shè)計，調(diào)優(yōu)技巧只是一個輔助手段。
• 調(diào)優(yōu)過程是迭代漸進的過程，每一次調(diào)優(yōu)的結(jié)果都要反饋到后續(xù)的代碼開發(fā)中去。
• 性能調(diào)優(yōu)不能以犧牲代碼的可讀性和可維護性為代價。