ElasticSearch version 2.1.1
第一次调优:
1."number_of_replicas": 0
构建索引的时候,可以先关闭replicas,等索引建立完毕之后在建立副本
2."refresh_interval": "-1"
构建索引的时候不需要实时refresh
3.translog 优化:
"translog": {
"sync_interval": "60s", --sync间隔调高
"durability": "async", – 异步更新
"flush_threshold_size":"1g" --log文件大小
}
4.禁用_all字段,减少一半的索引空间
"_all": {
"enabled": false
}
5. 使用node client ,减少一次网络传输
6.bulk size依据各自网络环境来定,我们的网络环境约54MB/s,每个bulk size的大小经过多次测试,设置为20MB,记录数10000条。
第一次调优结果:32台节点的es集群,平均写入速度能到2.8万每秒。
第二次调优:
32台节点es集群,最终达到每秒13.33万记录。每条记录约为1.2kb,也就是每秒133M的索引生成速度。
总结:随着ES shard的增多,es的索引生成速度是可以随之上升的。为了满足每个shard都到达自己的极限,就要加大bulk size,从而保证给每个shard充足的数据。
第二次调优测试详情
序号 | 执行时间 | 测试环境 | 任务描述 | 数据量 | 调优参数 | 执行时资源状况 | 执行结果 | 结果分析 | 备注 |
1 | 2016-06-02 14:13:00 | 单节点es(8c 32g hhd)version:2.1.1 单片shard 单节点dc 使用nodeclient | dc从hdfs上读取一片policy索引文件(50GB),持续写入es,执行60分钟。 | policy es共有61个字段。 hdfs上面一条policy数据大小约为455bit.(纯value)组装成json后发给es,10000条数据约为12mb,平均每条数据为1.2kb | 基线配置: shards=1 replicas=0 refresh_interval=-1
bulksize=20Mb bulkaction=10000 bulkconcurrentRequest=2
_all: disable "translog": { "sync_interval": "60s", "durability": "async", "flush_threshold_size":"1g" } | cpu load average: 1.70, 1.77, 1.58 内存:12次fgc | 执行60分钟后,总共生成数量:1426万条记录。 平均速度:3961条/秒 | 单节点和单片shard,的性能明显不理想。 这种场景不需要分发,不需要路由,就直接在一个shard上面生成索引,按道理应该非常快才对。 而且观察过程中,明显发现随着build时间的增长,索引的构建速度会越来越慢。 | 各项机器资源均没有吃满,但索引速度就是上不去。 |
2 | 2016-06-02 | 同上 | 同上 | 同上 | 修改warmer设置: setting index.warmer.enabled to false | 执行14分钟后,生成395万,平均4702条/秒; 34分钟后生成859万记录,平均4210条/秒。 | 性能提升不大 | 这个配置不能动态修改,所以不能用。 | |
3 | 2016-06-02 16:44:00 | 同上 | 同上 | 同上 | 去掉translog的优化配置,变成默认值: "translog": { "flush_threshold_size":"512m", "durability": "request" } | 执行22分钟后,生成记录388万条,平均2732条/秒; 执行108分钟后,生成记录1865万条,平均2878条/秒; | 说明translog 的调优参数是有用的,性能提升明显,提高了将近每秒1000条,提升30%。 | ||
4 | 2016-06-03 | 同上 | 同上 | 同上 | 调大bulksize: bulksize=200Mb bulkaction=100000 bulkconcurrentRequest=2 | 执行162分钟后,数据量3530万,平均3631条/秒; | 调大bulk size并没有效果,单个节点的最大速度(瓶颈)就是4千条/秒。 | ||
5 | 2016-06-13 16:54:00 | 基本同上,但es jvm=16G | 同上 | 同上 | 基线配置 | cpu load average: 1.82,1.75,1.33 | 执行60分钟后,数据量1169万,平均3247条/秒; | 可见降低jvm内存分配,索引速度会下降。虽然官方建议jvm内存不要超过50%,留剩下的内存给lucene。 | |
6 | 2016-06-13 18:24:00 | 3个es节点,3片shard,3个dc | 同上 | 同上 | 基线配置 | 执行21分钟后,数量1716万,平均1.36万条每秒,分到每个shard和dc上是每秒4533条。 --- 执行37分钟后,总量2841万,平均每秒1.27万条,分到每台dc上平均每秒4265条 --- 执行17个小时之后,总量59640,平均每秒9745条,分到每台dc上平均每秒3248条 | 多个shard就面临是否要事先路由的问题。 经过分析研究,事先路由也没有用,因为: 1.事先路由需要大量的内存来存放不同shard的数据 2.node client 内部出来bulk request时候,其实 同样做了这一步,把bulk requst里面的document按照不同shard放到不同的map里面。 | ||
7 | 2016-06-14 15:03:00 | 3个es节点,3片shard,1个dc | 执行35分钟后,数量1500万,平均每秒7142条记录,分到每个shard为2380条 | 单节点往3个shard写入,瓶颈是在dc,而不是在shard | |||||
8 | 2016-06-14 16:18:00 | 3个es节点,3片shard,3个dc 使用transport方式 | 执行40分钟,数据量为2730万,平均每秒1.1375万条,分到每台dc为3791条 | 相比node client 方式,性能出现了10%左右的下降。 | |||||
9 | 2016-06-14 17:30:00 | 3个es节点,9片shard,3个dc | 调大bulksize: bulksize=200Mb bulkaction=100000 bulkconcurrentRequest=2 | cpu load: 4.94,4.61,4.33 | 执行23分钟时,总数据量3060万,平均每秒2.21万条,分到每台shard是2455。 ----- 执行到46分钟,中数据了6030万,平均每秒2.18万条,分到每台shard是2422 | 当节点不变,shard增多时,索引的性能会提高。 由于shard增多,此时加大bulk size 变得有意义,100000意味着每个shard都有可能得到1万多的数据。dc在bulk里面会给每个shard 一次发送1万多的数据。 | 当一台server上面,同时存在3个shard时,大量写入索引,会引起cpu load 升高。此时的gc状态良好,没有出现频繁gc现象。 但cpu load 飙高可能会导致search出现缓慢超时。 | ||
10 | 2016-06-14 18:24:00 | 5个es节点,9片shard,3个dc | 调大bulksize: bulksize=200Mb bulkaction=100000 bulkconcurrentRequest=2 | cpu load: 1.83,1.65,1.80 | 执行36分钟后,总量6300万,平均每秒2.91万条,均分到每台shard是3233条 | 当节点增多后,cpu负载下降,性能提高。快要到达每个shard的瓶颈4000。 在node client模式下,bulkactions是直接由dc分发到相应的shard,为了保证每个shard吃满数据,bulkaction应该= shard*10000; | |||
11 | 2016-06-15 15:00:00 | 5个es节点,9片shard,3个dc 使用transport方式
|
调大bulksize: bulksize=200Mb bulkaction=100000 bulkconcurrentRequest=2
| cpu load: 1.87,1.74,1.71 | 执行30分钟后,总量4740万,平均每秒2.63万条 | transport方式性能并没有因为多转发一次,而大量下降。 还是10%左右。 | |||
12 | 2016-06-15 15:57:00 | 32个es节点,32个shard,3个dc es jvm=28G | 基线配置 | es cpu load 0.76,0.64,0.44 | 执行36分钟后,总量4761万,平均每秒2.20万条,分到每个shard,每秒687条。 | es加的,shard加的,bulk size 不加大的时候,性能没有上去。 | |||
13 | 2016-06-15 16:45:00 | 32个es节点,32个shard,3个dc es jvm=28G | 调大bulksize: bulksize=200Mb bulkaction=100000 bulkconcurrentRequest=2 | cpu load 1.44 1.14 1.08 | 执行50分钟后,总量12900万,平均每秒4.3万条,分到每个shard,每秒1343条记录 | 增加bulk size 显著提高性能 | |||
14 | 2016-06-15 18:12:00 | 32个es节点,32个shard,3个dc es jvm=28G | 调大bulksize: bulksize=600Mb bulkaction=300000 bulkconcurrentRequest=2 | cpu load 1.23,1.12,0.98 | 执行30分钟后,总量9000万,平均每秒5万条记录,按每shard为1562条。 | 进一步增大bulk size后,性能再一次提高13%。 | DC节点内存8G内存溢出,增大到16G | ||
15 | 2016-06-16 11:00:00 | 32个es节点,32个shard,4个dc es jvm=28G | 调大bulksize: bulksize=600Mb bulkaction=300000 bulkconcurrentRequest=2 | cpu load 1.63 1.53 1.26 | 执行30分钟,总量11640万,平均每秒6.46万条记录,按照每shard为2018条。 | 增加一台DC节点,性能再一次提高30% | |||
16 | 2016-06-16 13:57:00 | 32个es节点,32个shard,4个dc es jvm=28G | 调大bulksize: bulksize=1000Mb bulkaction=500000 bulkconcurrentRequest=2 | cpu load 3.31,3.06,2.52 | 执行30分钟,总量11650万,平均每秒6.47万条记录,按shard为每秒2021条。 | 再进一步增大bulk size 没有带来性能提升。反而造成DC节点内存消耗严重。 | DC 16G内存不够用,增大到20G,还有一台内存溢出。 | ||
17 | 2016-06-16 15:51:00 | 32个es节点,32个shard,5个dc es jvm=28G | 调大bulksize: bulksize=600Mb bulkaction=300000 bulkconcurrentRequest=2 | cpu load 2.52,2.02,2.12 | 执行30分钟,总量15150万,平均每秒8.41万条记录,按照shard为每秒2628条。 | 再增加一台DC节点,性能再一次提高30%。 | 每个shard都还没有到达瓶颈,所以可以继续增加DC节点。 | ||
18 | 32个es节点,32个shard,8个dc es jvm=28G | 调大bulksize: bulksize=600Mb bulkaction=300000 bulkconcurrentRequest=2 | cpu load 4.05,4.00,3.03 | 执行30分钟,总量24000万,平均每秒13.33万记录,按照shard为每秒4062条记录 | 已经到达单台shard的上限。 此时还会导致cpu load 飙高,正常的search查询速度经验证,受到很大影响。 | 为了不影响search的查询速度,不建议8台DC,而是4台DC。 30亿数据8台dc执行,需要6个小时。 4台dc执行,需要13个小时。 时间从72小时,减少到13小时,已经提高非常大,时间已经可以接受。 |
第三次调优:
虽然经过第二次调优,写性能可以达到极限,但此时cpu,内存能占用飙升,会严重影响es集群的读性能。
说明一味地往online集群写数据已经不合适了。
我们采用了离线集群来写数据,然后再将离线集群生成好的索引,copy到online集群方式,来避免这个问题。