Elasticsearch性能优化总结

1、前言

用了很久的ElasticSearch终于想给自己以及大家总结一份调优文档了。我的集群是10台ElasticSearch，内存是每台16G，2core的CPU，硬件资源并不好。所以对于调优工作就更要认真做好了。如果大家有条件选择SSD就更加好，这样能大大提高ElasticSearch的速度和性能。

2、内存设置

由于本身的资源不好，所以设置内存极为重要。同时ElasticSearch是基于lucene，而lucene是通过内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中，并且不可变。同时ES，他会将索引存入cache中，以便快速访问。所以内存的优化。需要给lucene和JVM。
1、服务器内存超过64G。也不需要给ES设置超过32G的内存，只需要给2~32G的内存即可，其他的内存留给服务器本身使用。
服务器内存低于64G，按50%设置，50%的内存给elaticSearch，其余内存给服务器本身使用。

2、对于内存紧张的服务器，可以锁定内存紧张swap，在elasticsearch.yml 中 bootstrap.memory_lock: true

3、由于elasticSearch是基于java开发的，所以也可以优化GC。但是，我们保持默认设置就好。垃圾回收CMS，线程池的设置。

4、设置elasticSearch堆内存最小值（Xms）与最大值（Xmx）一定要相同（JVM.option），通过和bootstrap.memory_lock: true一起配合使用。

3、索引设置

3.1 分片

1、elasticSearch创建好索引时会指定分片的数量，创建好后，不能更改分片数量。原则我们需要评估我们的数据有好多。每一个索引的空间最好是在10-30G，也有人说每一个分片不要超过JVM设置的堆的内存。

2、分片的设置有时候也和服务器的数量有关系，一般分片数量也不会超过服务器的3-4倍。

3、默认的分片数是5个，

3.2 副本

1、默认创建一个副本，就是每个分片都是一个副本分片。可以根据我们集群节点的多少和我们的存储空间觉得。空间多可以多设置副本。一般是1-3个副本数。副本数可以动态调整。

3.3 Mapping设置

1、尽量避免使用nested或parent/child。能不用就不用；nested query慢，parent/child query更慢，比nested query满上百倍。故能用大宽表搞定就不要使用。

2、如果一定要使用nested fields,保证nested fields字段不能过多，目前ES默认限制是50.主要是通过配置
index.mapping.nested_fields.limit:50

3、避免使用动态值作为字段（key）,动态递增的mapping,不需要的字段就不需要索引。
index.mapping.nested_objects.limit :10000
index.mapping.total_fields.limit:1000
index.mapping.depth.limit: 20

3.4 索引优化

1、index.refresh_interval: 是数据写入后几秒后被搜索到，默认是1s ,如果对于实时性要求不高。可以把时间设置为30S 甚至更高。你会发现你的CPU瞬间减低。

2、优化index_buffer_size的设置，默认是10%和48mb ，如果看中并发写入操作，最好提高indeices.memory.index_buffer_size调大一些。
indices.memory.index_buffer_size：10%（默认） indices.memory.min_index_buffer_size： 48mb（默认）

3、translog的设置
（1）减少内存到硬盘的操作频率，减少硬盘IO。默认是5S。可以提高这个时间10S，20S，根据你的实际设置。
index.translog.sync_interval：5s(默认)。
（2）设置log的大小，当达到threshold大小时，才flush到Lucene所以文件。默认是512mb(默认)。可以调到1g
index.translog.flush_threshold_size：512mb(默认)
（3）设置为异步写入磁盘，，有助于写入性能的提升。

4、_id的选择。减少使用自定义_id，使用默认自身生成_id。

5、_all字段和_source字段的选择。_all字段包含所有的索引字段，方便全文检索，无使用的需求，可以禁止。_source存储原始的document内容，如果不使用原始数据的需求，可通过设置includes、excludes属性来定义放入_source的字段。

6、合理使用analyzed和not_analyzed。如果数据使用group by的字段需求。配置时就设置成not_analyzed，以提高查询或聚类的效率。

4、查询优化

1、日期字段的查询，使用now的查询实际是不存在缓冲的。因此，可以从业务的角度来考虑是否一定要用now，毕竟使用query cache 能大大提高查询效率。

2、查询的结果集不能超过 Integer.MAX_VALUE 即 2147483647

3、避免层级过深的聚合查询， 层级过深的group by , 会导致内存、CPU消耗，建议在服务层通过程序来组装业务，也可以通过pipeline的方式来优化。

4、范围性range agg 查询时变为terms agg。可以新增一个范围字段，预先分类。只需查询分类字段即可。

5、filter查询会使用cache。即可以提高cache.size。
indices.queries.cache.size： 10%（默认）

5、集群节点优化

• discovery.zen.ping.timeout:选举过程中，发现其他node存活的超时设置。
• discovery.zen.fd.ping_interval:节点通讯的的频率，检测节点是否存活。
• discovery.zen.fd.ping_timeout:节点存活响应。默认30S。
• discovery.zen.fd.ping_retries:ping失败/超时多少导致节点被视为失败，默认为3。