针对elasticsearch在200并发持续测试下的cpu、内存监控(使用highlight与不使用highlight)

最新推荐文章于 2024-08-13 10:49:55 发布

bizlife

最新推荐文章于 2024-08-13 10:49:55 发布

阅读量5.2k

点赞数

分类专栏： elasticsearch 文章标签： elasticsearch jvm jvisualvm 索引虚拟机

本文链接：https://blog.csdn.net/bizlife/article/details/71191289

版权

elasticsearch 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

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%的状态