《軟件性能測試、分析與調優實踐之路》(第2版)--第7章節選--常見性能問題分析總結

1. 性能指標曲線頻繁出現大幅度抖動

如圖7-5-1所示,TPS和平均響應時間出現頻繁的上下抖動。頻繁抖動說明系統並不是一直在穩定地運行,中間會有短暫的停頓,就是持續運行了一段時間後,馬上會停頓一下,然後又繼續運行,持續地這樣交替進行,造成了系統的頻繁劇烈抖動。

   
圖7-5-1

造成頻繁抖動現象的原因可能有以下幾種:(節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

(1)系統可能在頻繁的出現Full GC。Full GC是Java 應用程序垃圾回收的一種機制,一般如果出現了Full GC,應用程序就會出現短暫的停頓。關於Full GC的介紹,可以參考本書5.1.7小節中的介紹。此時可以先去看一下應用程序的GC日誌,如果是Full GC 非常頻繁,並且又沒有出現內存泄漏,那麼可以參考本書5.4.1 小節中介紹的如何減少GC 來解決這個問題。

(2)系統某一次查詢、修改或者刪除數據耗時很長,導致了整體性能的不穩定。比如,在性能壓測查詢時,大部分參數化傳入的參數,查詢出來的結果數據都很少,但是可能某幾個參數查詢出來的數據量非常大,導致系統在處理這些數據量大的數據時耗時較長。

(3)系統在查詢時,可能有時候能命中緩存,有時候命不中緩存。命中緩存時,查詢會很快;不能命中緩存時,需要去查詢數據庫,但是查詢數據庫的時間肯定比緩存長,所以就會造成系統性能的不穩定。通常情況下數據庫也會有緩存,如果命中了數據庫的緩存,查詢也會更快;如果沒有命中,那查詢的耗時肯定也會變久。

(4)如果系統是分佈式部署,那麼可以檢查一下分佈式處理系統中每個節點的處理能力是否一致,如果不一致,可能也會導致系統頻繁抖動。

(5)服務器連接不夠用導致的連接批量釋放然後再突然批量連接,一旦批量釋放連接後,系統TPS馬上就會上漲,因爲此時可以建立連接了。當連接滿了後,請求就無法處理了,從而不得不等待,進而造成TPS突然下降。

2.在提高併發用戶數時,系統的TPS和平均響應時間一直無法提升

如圖7-5-2所示,當遇到這種情況時,說明系統已經出現了瓶頸,此時可以先去檢查服務器的CPU、內存資源的消耗情況。

 

圖7-5-2

通常,檢查後會發現應用服務器的CPU、內存等資源都沒有達到使用的上限,但是系統卻出現了處理的瓶頸,那麼說明系統一定是有地方“堵住了”。此時需要繼續做如下檢查:

(1)性能壓測時,點擊率是否真的上來了。如果點擊率或者單位時間內的請求數沒有上來,那說明是壓測機器無法提供更大壓測能力。尤其在大型的分佈式系統中,單臺壓測機往往是不夠用的,因爲單臺壓測機不論是網絡連接,還是帶寬以及自身CPU、內存等都會存在很大限制,性能壓測不止是服務器資源會有很大消耗,提供壓測能力的壓測機也會很大的資源消耗。

(2)檢查網絡帶寬的使用情況,排查瓶頸是否因爲網絡帶寬限制而導致。此時,需要檢查網絡帶寬的環節包括壓測機到Web服務器、Web服務器到應用服務器、應用服務器到數據庫服務器等所有存在網絡請求交互的地方。如圖7-5-3所示。(節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

圖7-5-3

(3)參考本書5.3.2小節中使用jstack命令行工具,查看Java系統的線程堆棧,從線程堆棧中直接分析當前系統的瓶頸是因爲在等待什麼資源,而且該資源可能是一個隱形的不容易發現的資源。

(4)如果對於第(3)點運用不熟的話,可以用最笨的方式就是根據請求處理的鏈路過程,從上而下或者從下而上按順序去排查。此時需要堅信一點,系統肯定是“堵在什麼地方了”,仔細通過checklist去檢查,一定能夠找到這個“堵住”的位置。這就如同自來水的供水系統一樣,如果某個用戶突然反饋說,我家自來水水壓很小,水壓一直都上不去,那麼自來水公司的維修人員上門之後,肯定是從這個用戶家作爲起點,然後對供水鏈路中的每個環節進行排查,直到找到是哪個環節出現了擁堵。 (節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

(5)如果按照前面四點還是找不到問題原因的話,那麼可以嘗試減少中間環節從而減少不確定因子的影響,再進行壓測對比,先確定問題可能的範圍,然後再在某個明確的範圍內查找具體的原因。比如如圖所示,將Web服務器去掉,讓壓測機的請求直接對應用服務器進行壓測。如圖7-5-4所示。

 

圖7-5-4

3在提高併發用戶數時,系統的TPS緩慢下降而平均響應時間緩慢上升

如圖7-5-5所示,當系統出現TPS下降而平均響應時間緩慢上升,可能是系統已經出現了性能的拐點,達到了最大的處理能力了。此時需要做一下如下檢查

 7-5-5

1)應用服務器資源,比如CPU、內存、IO等是否已經達到了使用上限。

2)數據庫服務器的資源以及數據庫的鏈接數等是否已經達到了使用上限。

3)如果第(1)點或者第(2)點中的資源使用已經達到了上限,可以對服務器資源進行擴容後,再重新繼續壓測。通常情況下,性能出現拐點時,服務器中某項資源也達到了使用的上限。

4. 性能壓測過程中,服務器內存資源使用率一直在逐步緩慢上升,隨着性能壓測的持續進行,從來不會出現下降或者在一定範圍內小幅度波動,並且此時TPS也在緩慢下降

 

 7-5-6

如圖7-5-6所示,當出現這種情況時,很有可能是出現了內存泄露,此時可以做如下檢查:

1)查看系統日誌,看看有沒有內存溢出的報錯信息。

2)在性能壓測過程中參考使用本書5.2.1小節中的jconsole或者5.2.2小節中的jvisualvm來進一步定位Java JVM 是否存在內存泄露。(節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

3)如果存在JVM 內存泄露,可以參考使用5.3.3小節中的MemoryAnalyzer工具來進一步分析是代碼中哪個地方出現了內存泄露。

4)性能壓測過程中,當併發用戶數和點擊率不變的情況下,服務器的資源消耗應該是在一個穩定的範圍內,或者在一定範圍內不斷地小幅度波動,這纔是比較正常的。

4)如果第(3)點無法排查到具體的問題,可以參考本書1.6.1小節中的分層分析的方式來定位問題。

5. 在分佈式部署環境下的性能壓測過程中出現每臺應用服務器CPU或者內存資源消耗相差太大

如圖7-5-7所示,當出現這種現象時,可以做如下排查:

1)檢查每臺應用服務器的硬件配置是否一致。(節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

2)檢查每臺應用服務器的操作系統,應用軟件、數據庫軟件、JDK軟件等版本以及配置信息是否一致。(節選自《軟件性能測試、分析與調優實踐之路》(第2版),作者張永清,轉載請註明出處)

3)如果第(1)點和第(2)點都沒問題,檢查Web服務器轉發請求到應用服務器的負載均衡是否均勻。比如Nginx配置中是否有轉發的權重不一致,或者有ip_hash等的配置限制,具體可以參考本書3.1.1小節中的介紹。

 7-5-7

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章