效能測試瓶頸分析

2021-06-07 07:02:36 字數 838 閱讀 9761

在效能測試過程中,瓶頸猶如功能測試的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...