效能測試瓶頸分析

在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位**。效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。

病象：tps波動非常大；狂打超時日誌；偶爾有500錯誤。

看到這個現象，其實說明不了什麼問題，就象人咳嗽，不一定是感冒，可能是上火，嗓子發炎。但是看到這個現象至少說明系統是有效能問題存在，我們就要進一步進行分析，看看問題到底在哪？用jconsole監控記憶體，發現記憶體使用如圖1

圖1：記憶體使用情況圖

從圖1中，我們可以很清晰的看到記憶體使用不正常，fgc非常頻繁，差不多5分鐘進行一次，而且記憶體**不徹底，每次**在1g左右徘徊。到這裡我們已經可以定位是記憶體問題，導致了我們看到的tps波動大，fgc頻繁，超時嚴重等等一系列現象。

那麼是誰吃了我的記憶體？？？

用簡單的jstat命令檢視系統gc情況，看到情況如圖2所示

圖2在圖2的綠色框標註，我們可以很清晰的看到進行一次fgc，記憶體只**12%左右，**很不徹底，而且fgc的時間持續5秒。記憶體**不徹底，肯定是有些方法霸佔了記憶體不釋放，導致系統頻繁fgc來進行**。

那麼誰是真正的**呢？？

用jmap 命令對記憶體使用進行分析，發現情況如圖3所示

圖3通過fgc前後的記憶體使用進行比對，發現這三個方法快速占用記憶體從最少到最多，而且**不掉，始終霸佔著前幾位。再通過其他工具分析，看看這三個是不是真正的**。

用mat分析工具進行分析，圖4所示

圖4這三個方法各佔了記憶體使用的14%，那麼問題就很清晰明朗了。這三個方法就是真正的**，調優就從這三個方法入手。

效能瓶頸的分析，猶如庖丁解牛，層層剖析。最終定位問題之所在。

效能測試瓶頸分析

在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位 效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象，其實說明不了什麼問題，就象...

效能測試瓶頸分析

在效能測試過程中，瓶頸猶如功能測試的bug，瓶頸的分析猶如bug的定位。效能測試工程師好比醫生，看到病象，定位 效能瓶頸的定位更像庖丁解牛，層層解剖，最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象，其實說明不了什麼問題，就象...

效能測試瓶頸分析

在實際測試中，由於各種原因，測試得到的效能指標關係往往並不遵循前面介紹的關係。常見的現象有cpu壓不滿或者在cpu壓滿前，相關效能指標曲線已不正常。雖然導致這種現象的原因很多，但有一點可以肯定的是，系統 硬體或軟體系統 的某處一定出現了瓶頸。此時，測試人員應配合開發人員進行分析盡快找出瓶頸的所在。1...