ElasticSearch索引构建速度调优

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 16:06:00	同上	同上	同上	修改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集群方式，来避免这个问题。