jmeter(五十一)_性能測試中的服務器資源監控與分析

概述

性能測試過程當中，對服務器資源的監控是必不可少的。這裏的資源又分了兩塊，windows和linux

 

linux下監控資源

訪問網址http://jmeter-plugins.org/downloads/all/，下載三個文件。其中JMeterPlugins-Standard和JMeterPlugins-Extras是客戶端的，ServerAgent是服務端的。

 

前兩個是jmeter擴展插件，解壓後將jar拷貝包到jmeter的lib/ext目錄下，最後一個是服務器監控插件，解壓到服務器上

將ServerAgent-2.2.1.zip解壓後放在須要監控的服務器上，並執行

chmod 777 startAgent.sh 賦權

./startAgent.sh 啓動監控

 

配置端口和ip，端口默認4444

服務器上能夠修改默認端口--./startAgent.sh –udp-port 0 –tcp-port XXXX

若是配置正確，可是始終沒法監控到服務器，須要考慮 4444  端口是否在服務器防火牆中被禁用！

 

運行查看結果

 

jmeter隱藏功能：指定進程號進行監控。須要雙擊空白的地方，右邊會出現三個點。這邊能夠根據服務器的pid進程號來監控資源

 

監控CPU

數值都是表明百分比，好比默認配置下在曲線圖中看到某個時間的數值是30，即表明此時總的cpu使用時間佔比爲30%。

兩點比較有用的地方值得說明：

1：在Scope區域，能夠經過Per Process選項來獲取指定進程的CPU使用狀況

2：在CPU Cores區域，咱們能夠選擇監控指定的單個Core。

監控Memory

usedperc(默認)和freeperc兩項的數值表明與總內存的百分比，其他指標項的數值都是指內存大小，選中對應項，能夠看到Metric Unit區域單位配置將變爲可用，一般Mb會比較適合觀察。一樣，也能夠選擇監控指定進程的數據

監控Disk I/O

queue(默認)的數值表明等待I/O隊列長度，reads、writes分別表明每秒處理的讀/寫次數，readbytes、writebytes顧名思義，表明每秒讀/寫的數據量，單位一樣在Metric Unit區域配置，一般Mb會比較適合觀察。若是有掛載多個存儲設備，能夠在Filesystem Filter區域指定要監控的設備

 

windows下的資源監控1---jconsole

jdk目錄下面有自帶的資源監控平臺--jconsole.exe

雙擊jconsole.exe，啓動監控平臺，能夠選擇須要監控的服務。能夠是本地的tomcat進程，也能夠是遠程的服務器。這裏我選擇了監控jmeter進程。

在上方的概覽中，咱們能夠看到堆內存，線程，類，cpu四個監控模塊。時間能夠自由選擇。

在內存選項中，咱們能夠選擇分別監控新生代，老年代，eden，space這些堆內存空間。同時能夠手動gc內存。

在線程中，咱們能夠監控全部已加載的線程，同時一鍵檢測線程死鎖。

在類中，咱們能夠直觀的看到各類性能數據。包括jmeter分配的線程池大小。

 

windows下的資源監控2---jmc工具，能夠監控本地和遠程機器

jmc的功能相似於jconsole，不過儀表盤式的外觀和色彩看起來更加漂亮。

在底部的按鈕能夠針對堆內存，cpu，線程等進行性能診斷

windows下的資源監控2---jvisualvm工具，能夠監控本地和遠程機器

 

 

jvisualvm的功能更增強大一些，除了常規的數據監控以外，還能夠對線程進行dump（只能針對本地，不能對遠程服務進行dump）

 

jdk自帶的監控工具是豐富多彩的，咱們能夠根據本身的需求去選擇不一樣的工具。

 

內存瓶頸分析

內存資源成爲系統性能的瓶頸的徵兆 :

• 很高的換頁率 (high pageout rate);

• 進程進入不活動狀態 ;

• 交換區全部磁盤的活動次數可高 ;

• 可高的全局系統 CPU 利用率 ; 

• 內存不夠出錯 (out of memory errors)

 

cpu瓶頸分析

CPU 資源成爲系統性能的瓶頸的徵兆 : 

• 很慢的響應時間 (slow response time) 

• CPU 空閒時間爲零 (zero percent idle CPU) 

• 太高的用戶佔用 CPU 時間 (high percent user CPU) 

• 太高的系統佔用 CPU 時間 (high percent system CPU) 

• 長時間的有很長的運行進程隊列 (large run queue size sustained over time)