1. 程式人生 > >針對elasticsearch在200併發持續測試下的cpu、記憶體監控(使用highlight與不使用highlight)

針對elasticsearch在200併發持續測試下的cpu、記憶體監控(使用highlight與不使用highlight)

elasticsearch環境:10.10.3.249:9200,10.10.3.248:9200,10.10.3.202:9200

elasticsearch cluster叢集:10.10.3.249:9300,10.103.248:9300,10.10.3.202:9300

master node:10.10.3.202

worker node:10.10.3.249,10.10.3.248

三臺虛擬機器的實體記憶體均為:8g

三臺虛擬機器的cpu核數:4 core

三個elasticsearch node結點jvm記憶體均為:4g

磁碟容量:1024g

索引名稱:domain 

索引大小:318g

type名稱:DeviceDataCurr

索引shard:5

索引repliset:5

kibana環境:10.10.3.249:5601

elasticsearch head:10.10.3.249:9100

1. 初始的記憶體使用情況:

master node :10.10.3.202 堆記憶體使用1.5g左右,cpu使用率 5%左右

 

worker node結點 :10.10.3.248 堆記憶體使用1g左右, cpu使用3%左右

  

worker node結點 :10.10.3.249 堆記憶體使用1g左右, cpu使用4%左右

 

2.測試api:採用term query+full text query 的方式

GET /domain/DeviceDataCurr/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "type.keyword": "config"
          }
        },
        {
          "match": {
            "content": "access-list 90"
          }
        }
      ]
    }
  },
  "_source": [
    "devId",
    "name",
    "devName",
    "sourceId",
    "sourceType",
    "type",
    "uploadDate",
    "pathData",
    "operateInfo",
    "length",
    "contentType"
  ],
  "from": 1,
  "size": 20,
  "sort": {
    "_score": {
      "order": "desc"
    }
  }
}

3、一個併發執行上面語句30分鐘後我們觀察jvm的cup、mem及os的cpu、mem的執行情況

master:10.10.3.202 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1.5g,cpu峰值出現在剛壓測的時候,達到65%的使用率

worker node:10.10.3.249 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1g,cpu峰值出現在剛壓測的時候,達到55%的使用率

worker node:10.10.3.248 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1g,cpu峰值出現在剛壓測的時候,達到55%的使用率

4、200併發執行上面語句30分鐘後我們觀察jvm的cup、mem及os的cpu、mem的執行情況

master node:10.10.3.202 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1.5g,cpu峰值達到100%的使用率,cpu波谷在80%

master node cpu最高負載達到7.5左右,實體記憶體最高使用達到7.9g

worker node:10.10.3.249 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1g,cpu峰值達到100%的使用率,cpu波谷在52%左右,

且明顯cpu沒有master node繁忙

10.10.3.249的cpu最高負載達到3.3左右,實體記憶體最高使用達到6.5g

worker node:10.10.3.248 cpu及記憶體使用情況,由下圖可以看出,cpu和記憶體都呈鋸齒狀,每當cpu處於如下箭頭所示的波峰時,記憶體也處於密集回收的狀態,而當cpu處於波谷的時候,記憶體回收不密集,記憶體保持在1g,cpu峰值達到100%的使用率,cpu波谷在52%左右,

且明顯cpu沒有master node繁忙

10.10.3.248的cpu最高負載達到2.7左右,實體記憶體最高使用達到6.5g

12.測試api:採用term query+full text query+highlight 的方式

GET /domain/DeviceDataCurr/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "type.keyword": "config"
          }
        },
        {
          "match": {
            "content": "access-list 90"
          }
        }
      ]
    }
  },
  "_source": [
    "devId",
    "name",
    "devName",
    "sourceId",
    "sourceType",
    "type",
    "uploadDate",
    "pathData",
    "operateInfo",
    "length",
    "contentType"
  ],
  "from": 1,
  "size": 20,
  "sort": {
    "_score": {
      "order": "desc"
    }
  },
  "highlight": {
    "fields": {
      "content": {}
    }
  }
}

13、200併發執行上面語句30分鐘後我們觀察jvm的cup、mem及os的cpu、mem的執行情況

master node:10.10.3.202 cpu及記憶體使用情況,由下圖可以看出,cpu幾乎全滿的狀態,且cpu使用率中用於gc的時間明顯增加,由於是highlight導致產生大量的old區物件,old區記憶體不斷的上升,直到觸發-XX:CMSInitiatingOccupancyFraction=75,jvm開始full gc,full gc後記憶體顯著下降 ,記憶體峰值達到3g,cpu峰值幾乎一直處於100%的狀態

10.10.3.202的cpu最高負載達到6.5左右,實體記憶體最高使用達到8g

worker node:10.10.3.249 cpu及記憶體使用情況,由下圖可以看出,cpu峰值達到100%,cpu平均值在75% ,記憶體峰值達到3g,

10.10.3.249的cpu最高負載達到1.8左右,實體記憶體最高使用達到6.8g

worker node:10.10.3.248 cpu及記憶體使用情況,由下圖可以看出,cpu幾乎全滿的狀態,且cpu使用率中用於gc的時間明顯增加,由於是highlight導致產生大量的old區物件,old區記憶體不斷的上升,直到觸發-XX:CMSInitiatingOccupancyFraction=75,jvm開始full gc,

full gc後記憶體顯著下降 ,記憶體峰值達到3g,cpu峰值幾乎一直處於100%的狀態

10.10.3.248的cpu最高負載達到4.8左右,實體記憶體最高使用達到6.8g

基於本次測試highlight查詢方式,可以發現以下4點:

1.cpu很繁忙,堆記憶體使用情況總體趨於平穩,os實體記憶體使用總體趨於平衡,沒有異常的波動。

2.master node的cpu使用率比worker node結點更高,master node的堆記憶體及系統記憶體使用率也要比worker node結點高

3.elasticsearch分配的堆記憶體為4g, master只峰值使用了3g左右,worker node峰值使用了3g,另一worker node 峰值只使用了1g左右

4.elasticsearch的虛擬機器cpu為4core,master的峰值load為7.5,worker node的峰值load為3.3和2.7,可適當調高master的cpu核心數

注:以上觀點只針對以上測試環境及測試語句有效,不一定覆蓋全面。如有更好的測試語句需要重新測試方可知道對記憶體cpu的影響。

此為highlight查詢方式記憶體及cpu使用情況

基於本次測試非highlight查詢方式得出以下的觀點
1.cpu很繁忙,堆記憶體使用情況總體趨於平穩,os實體記憶體使用總體趨於平衡,沒有異常的波動。

2.master node的cpu使用率比worker node更高,master node的堆記憶體及系統記憶體使用率也要比worker node高

3.elasticsearch分配的堆記憶體為4g, master node只使用了1.5g左右,worker node只使用了1g左右

4.elasticsearch的虛擬機器cpu為4core,master node的峰值load為7.5,worker node的峰值load為3.3和2.7,可適當調高master node的cpu核心數

注:以上觀點只針對以上測試環境及測試語句有效,不一定覆蓋全面。如有更好的測試語句需要重新測試方可知道對記憶體cpu的影響。

 此為非highlight查詢方式記憶體及cpu使用情況