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使用情况