调优过程
| refresh间隔 | 副本数 | 总耗时 | bulk 量 | translog条数 | translog大小 | 文档总数 | 速度 | 备注 |
| 1s | 2 | 130min | 1000 | 5000 | 512 MB(默认) | 15kw | 11.5W/min | |
| 1s | 2 | 90min | 2000 | 5000 | 512 MB(默认) | 17kw | 18.8W/min | |
| 60s | 2 | 40min | 2000 | 5000 | 512 MB(默认) | 15KW | 37.5W/min | |
| 60s | 2 | 47min | 2000 | 5000 | 512 MB(默认) | 17KW | 36.1W/min | |
| 60s | 0 | 25min | 2000 | 5000 | 512 MB(默认) | 17kw | 68W/min | |
| 60s | 0 | 28min | 2000 | 10000 | 1g | 17kw | 60.7W/min |
es日志可以看出 merge限制了索引的速度 |
所以创建流程图
所以优化从几个点开始：减少segment 优化translog 以及缩减es的文档大小
1、调整mapping；缩小索引大小
1、去掉_all _all:{"enabled":"false"}
2、如果分词不参与打分”norms”：false
3、不需要短语搜索可以禁用positions： "indexe_options":"freqs"
4、source启用压缩 _source:{"compress":"true"}
2、设置refresh时间 为60s
3、设备segement和合并磁盘限制
段合并是很消耗计算资源和磁盘IO的操作，特别是出现比较大的段合并。 当出现段合并的速度落后于索引写入的速度，Elasticsearch为了避免出现堆积的段数量爆发，会降低单个线程的索引写入速度，并且会在INFO的log里记录“now throttling indexing”Elasticsearch默认比较保守，不想让搜索的性能被后台的段合并影响，默认的段合并速率限制比较低，默认是20MB/s。可以通过grep es的日志，看下日志里面 now throttling indexing 多不多。如果不多说明合并的速度并没有落后与写入的速度。
设置限制大小：indices.store.throttle.max_bytes_per_sec：100m
如果没有搜索可以把限制关掉
"indices.store.throttle.type" : "none"
索引完在打开
"indices.store.throttle.type" : "merge"
如果3设置好的话，不需要设置2的，因为3设置好的话表示segment量少，并且大。这样的话merge的几率会少，并且有利于搜索 。
4、设置translog
1、设置flush时间默认是30min
2、设置log文件大小，默认是512M 改为1g index.translog.flush_threshold_size
3、设置文件条数限制：index.translog.flush_threshold_ops 默认5K改为1W
4、每次flush是同步的过程，需要等待全部flush完成后写入在响应，所以需要改成异步写入