1.Elasticsearch部署建议

1.1. 选择合理的硬件配置：尽可能使用 SSD

Elasticsearch 最大的瓶颈往往是磁盘读写性能，尤其是随机读取性能。使用SSD（PCI-E接口SSD卡/SATA接口SSD盘）通常比机械硬盘（SATA盘/SAS盘）查询速度快5~10倍，写入性能提升不明显。
对于文档检索类查询性能要求较高的场景，建议考虑 SSD 作为存储，同时按照 1:10 的比例配置内存和硬盘。对于日志分析类查询并发要求较低的场景，可以考虑采用机械硬盘作为存储，同时按照 1:50 的比例配置内存和硬盘。单节点存储数据建议在2TB以内，不要超过5TB，避免查询速度慢、系统不稳定。

1.2. 给JVM配置机器一半的内存，但是不建议超过32G

修改 conf/jvm.options 配置，-Xms 和 -Xmx 设置为相同的值，推荐设置为机器内存的一半左右，剩余一半留给操作系统缓存使用。JVM 内存建议不要低于 2G，否则有可能因为内存不足导致 ES 无法正常启动或内存溢出，JVM 建议不要超过 32G，否则 JVM 会禁用内存对象指针压缩技术，造成内存浪费。机器内存大于 64G 内存时，推荐配置 -Xms30g -Xmx30g。JVM 堆内存较大时，内存垃圾回收暂停时间比较长，建议配置 ZGC 或 G1 垃圾回收算法。

1.3. 规模较大的集群配置专有主节点，避免脑裂问题

Elasticsearch 主节点负责集群元信息管理、index 的增删操作、节点的加入剔除，定期将最新的集群状态广播至各个节点。在集群规模较大时，建议配置专有主节点只负责集群管理，不存储数据，不承担数据读写压力。
# 专有主节点配置(conf/elasticsearch.yml)： node.master:true node.data: false node.ingest:false # 数据节点配置(conf/elasticsearch.yml)： node.master:false node.data:true node.ingest:true
Elasticsearch 默认每个节点既是候选主节点，又是数据节点。最小主节点数量参数 minimum_master_nodes 推荐配置为候选主节点数量一半以上，该配置告诉 Elasticsearch 当没有足够的 master 候选节点的时候，不进行 master 节点选举，等 master 节点足够了才进行选举。
例如对于 3 节点集群，最小主节点数量从默认值 1 改为 2。
# 最小主节点数量配置(conf/elasticsearch.yml)： discovery.zen.minimum_master_nodes: 2

1.4. Linux操作系统调优

关闭交换分区，防止内存置换降低性能。
# 将/etc/fstab 文件中包含swap的行注释掉 sed -i ‘/swap/s/^/#/‘ /etc/fstab swapoff -a # 单用户可以打开的最大文件数量，可以设置为官方推荐的65536或更大些 echo “ - nofile 655360” >> /etc/security/limits.conf # 单用户线程数调大 echo “ - nproc 131072” >> /etc/security/limits.conf # 单进程可以使用的最大map内存区域数量 echo “vm.max_map_count = 655360” >> /etc/sysctl.conf # 参数修改立即生效 sysctl -p

2.索引性能调优建议

2.1. 设置合理的索引分片数和副本数

索引分片数建议设置为集群节点的整数倍，初始数据导入时副本数设置为 0，生产环境副本数建议设置为 1（设置 1 个副本，集群任意 1 个节点宕机数据不会丢失；设置更多副本会占用更多存储空间，操作系统缓存命中率会下降，检索性能不一定提升）。单节点索引分片数建议不要超过 3 个，每个索引分片推荐 10-40GB 大小，索引分片数设置后不可以修改，副本数设置后可以修改。
Elasticsearch6.X 及之前的版本默认索引分片数为 5、副本数为 1，从 Elasticsearch7.0 开始调整为默认索引分片数为 1、副本数为 1。

2.1.1 索引设置

curl -XPUT http://localhost:9200/fulltext001?pretty -H ‘Content-Type: application/json’ -d ‘{ “settings”: { “refresh_interval”: “30s”, “merge.policy.max_merged_segment”: “1000mb”, “translog.durability”: “async”, “translog.flush_threshold_size”: “2gb”, “translog.sync_interval”: “100s”, “index”: { “number_of_shards”: “21”, “number_of_replicas”: “0” } } }’

2.1.2 mapping 设置

curl -XPOST http://localhost:9200/fulltext001/doc/_mapping?pretty -H ‘Content-Type: application/json’ -d ‘{ “doc”: { “_all”: { “enabled”: false }, “properties”: { “content”: { “type”: “text”, “analyzer”: “ik_max_word” }, “id”: { “type”: “keyword” } } } }’

2.1.3 写入数据示例

curl -XPUT ‘http://localhost:9200/fulltext001/doc/1?pretty‘ -H ‘Content-Type: application/json’ -d ‘{ “id”: “https://www.huxiu.com/article/215169.html“, “content”: ““娃娃机，迷你KTV，VR体验馆，堪称商场三大标配‘神器’。”一家地处商业中心的大型综合体负责人告诉懂懂笔记，在过去的这几个月里，几乎所有的综合体都“标配”了这三种“设备”…” }’

2.1.4 修改副本数示例

curl -XPUT “http://localhost:9200/fulltext001/_settings“ -H ‘Content-Type: application/json’ -d ‘{ “number_of_replicas”: 1 }’

3. 使用批量请求

使用批量请求将产生比单文档索引请求好得多的性能。写入数据时调用批量提交接口，推荐每批量提交 5~15MB 数据。例如单条记录 1KB 大小，每批次提交 10000 条左右记录写入性能较优；单条记录 5KB 大小，每批次提交 2000 条左右记录写入性能较优。

3.1 批量请求接口API

curl -XPOST “http://localhost:9200/_bulk“ -H ‘Content-Type: application/json’ -d’ { “index” : { “_index” : “test”, “_type” : “_doc”, “_id” : “1” } }{ “field1” : “value1” } { “delete” : { “_index” : “test”, “_type” : “_doc”, “_id” : “2” } } { “create” : { “_index” : “test”, “_type” : “_doc”, “_id” : “3” } }{ “field1” : “value3” } { “update” : {“_id” : “1”, “_type” : “_doc”, “_index” : “test”} }{ “doc” : {“field2” : “value2”} }’

4. 通过多进程/线程发送数据

单线程批量写入数据往往不能充分利用服务器 CPU 资源，可以尝试调整写入线程数或者在多个客户端上同时向 Elasticsearch 服务器提交写入请求。与批量调整大小请求类似，只有测试才能确定最佳的 worker 数量。可以通过逐渐增加工作任务数量来测试，直到集群上的 I/O 或 CPU 饱和。

5. 调大refresh interval

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。
并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件，你可能想优化索引速度而不是近实时搜索，可以通过设置 refresh_interval，降低每个索引的刷新频率。

设置 refresh interval API

curl -XPUT “http://localhost:9200/index“ -H ‘Content-Type: application/json’ -d’{ “settings”: { “refresh_interval”: “30s” } }’
refresh_interval 可以在已经存在的索引上进行动态更新，在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来。
curl -XPUT “http://localhost:9200/index/_settings“ -H ‘Content-Type: application/json’ -d’{ “refresh_interval”: -1 }’ curl -XPUT “http://localhost:9200/index/_settings“ -H ‘Content-Type: application/json’ -d’{ “refresh_interval”: “1s” }’

6. 配置事务日志参数

事务日志 translog 用于防止节点失败时的数据丢失。它的设计目的是帮助 shard 恢复操作，否则数据可能会从内存 flush 到磁盘时发生意外而丢失。事务日志 translog 的落盘(fsync)是 ES 在后台自动执行的，默认每 5 秒钟提交到磁盘上，或者当 translog 文件大小大于 512MB 提交，或者在每个成功的索引、删除、更新或批量请求时提交。
索引创建时，可以调整默认日志刷新间隔 5 秒，例如改为 60 秒，index.translog.sync_interval: “60s”。创建索引后，可以动态调整 translog 参数，“index.translog.durability”:“async” 相当于关闭了 index、bulk 等操作的同步 flush translog 操作，仅使用默认的定时刷新、文件大小阈值刷新的机制。
# 动态设置 translog API curl -XPUT “http://localhost:9200/index“ -H ‘Content-Type: application/json’ -d’{ “settings”: { “index.translog.durability”: “async”, “translog.flush_threshold_size”: “2gb” } }’

7. 设计mapping配置合适的字段类型

Elasticsearch 在写入文档时，如果请求中指定的索引名不存在，会自动创建新索引，并根据文档内容猜测可能的字段类型。但这往往不是最高效的，我们可以根据应用场景来设计合理的字段类型。
# 例如写入一条记录 curl -XPUT “http://localhost:9200/twitter/doc/1?pretty“ -H ‘Content-Type: application/json’ -d’{ “user”: “kimchy”, “post_date”: “2009-11-15T13:12:00”, “message”: “Trying out Elasticsearch, so far so good?” }’
查询 Elasticsearch 自动创建的索引 mapping，会发现将 post_date 字段自动识别为 date 类型，但是 message 和 user 字段被设置为 text、keyword 冗余字段，造成写入速度降低、占用更多磁盘空间。
{ “twitter”: { “mappings”: { “doc”: { “properties”: { “message”: { “type”: “text”, “fields”: { “keyword”: { “type”: “keyword”, “ignore_above”: 256 } } }, “post_date”: { “type”: “date” }, “user”: { “type”: “text”, “fields”: { “keyword”: { “type”: “keyword”, “ignore_above”: 256 } } } } } }, “settings”: { “index”: { “number_of_shards”: “5”, “number_of_replicas”: “1” } } } }
根据业务场景设计索引配置合理的分片数、副本数，设置字段类型、分词器。如果不需要合并全部字段，禁用 _all 字段，通过 copy_to 来合并字段。
curl -XPUT “http://localhost:9200/twitter?pretty“ -H ‘Content-Type: application/json’ -d’{ “settings”: { “index”: { “number_of_shards”: “20”, “number_of_replicas”: “0” } } }’ curl -XPOST “http://localhost:9200/twitter/doc/_mapping?pretty“ -H ‘Content-Type: application/json’ -d’{ “doc”: { “_all”: { “enabled”: false }, “properties”: { “user”: { “type”: “keyword” }, “post_date”: { “type”: “date” }, “message”: { “type”: “text”, “analyzer”: “cjk” } } } }’
查询性能调优建议

1. 使用过滤器缓存和分片查询缓存
   默认情况下，Elasticsearch 的查询会计算返回的每条数据与查询语句的相关度，但对于非全文索引的使用场景，用户并不关心查询结果与查询条件的相关度，只是想精确地查找目标数据。此时，可以通过 filter 来让 Elasticsearch 不计算评分，并且尽可能地缓存 filter 的结果集，供后续包含相同 filter 的查询使用，提高查询效率。

   8. Elasticsearch调优参数说明

   1.GC_OPTS:
   30G是我们给的一个保守的推荐值，为了确保JVM指针压缩开启。因为JVM在内存小于32GB的时候会采用一个内存对象指针压缩技术，至于小于32GB多少，不同的JVM和操作系统是不一样的，因为我们发现有31GB也未开启指针压缩功能的情况，所以给了一个比较保守的30GB。如果确定31GB的时候，已经开启了指针压缩，该参数可以不做调整。
   可通过如下命令查询JVM的指针压缩是否开启：
   java -server –Xms31G –Xmx31G -XX:+UseConcMarkSweepGC -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -version
   若返回的Compressed Oops mode是Zero based模式，则说明JVM指针压缩已开启， 若返回的Compressed Oops mode是Non-zero based模式，则说明JVM指针压缩未开启，需要减小所分配的GC大小。
   2. cluster.routing.allocation.cluster_concurrent_rebalance
   集群级别平衡过程中的shard并发度。
   如果集群中分片分布不平衡，集群会自动迁移分片来平衡各实例上的分片数。并发度过大会影响业务速度。如果集群存在极度不均衡的情况，可停止业务，调大并发度先让集群快速均衡后再开启业务。
   3. cluster.routing.allocation.node_concurrent_recoveries
   单个节点上恢复分片的并发数。
   节点启动或失败、主分片复制、分片迁移、快照还原都会涉及到分片恢复。
   集群规模较大的情况下，该参数过小会影响集群分片恢复速度。
   4. cluster.routing.allocation.node_initial_primaries_recoveries
   单个节点上初始化主分片的并发数。
   如新建一个索引或者节点刚重启时，分片都会短暂处于initializing状态。
   集群规模较大的情况下，该参数过小会影响集群主分片初始化速度。
   5. discovery.zen.fd.ping_retries
   失败或超时后重试的次数
   discovery.zen.fd.ping_interval
   节点被ping的周期
   discovery.zen.fd.ping_timeout
   等待ping响应的超时时间
   discovery.zen.ping_timeout
   实例开始选举或加入现有集群的超时时间
   以上参数是集群发现机制相关参数，发现是在主机未知的情况下（例如，当节点刚刚启动时或先前的主机发生故障时），节点之间相互查找的过程。该机制负责发现节点，选举主节点，形成集群并在每次更改时发布集群状态。增加超时时间、重试次数等是为了在网络压力大的情况下各节点可以相互发现形成集群。增大节点ping周期，是为了避免节点之间ping过于频繁。
   6. gateway.recover_after_time
   等待多少时间之后，集群开始强制进行数据恢复。
   有时集群某个节点会暂时下电，后很快恢复，或者某个节点进行重启，我们不希望这种情况下，集群也进行自动恢复，因为下电或重启的节点马上就会上线。如果某个节点暂时下线后短时间内集群就进行恢复该节点上的分片，当该节点很快再次上线后会被告知之前的数据已被重新分配，他会删除原来的数据，重新从其他节点拷贝分片数据，这又触发了一次恢复，同时还有分片的迁移，十分影响效率。
   7. bootstrap.memory_lock
   内存锁定
   启动该参数来禁用swap内存，禁止操作系统内存交换，参考ES官方文档：
   
   8. thread_pool.bulk.queue_size
   bulk线程池等待队列大小。
   bulk队列线程数超过该大小会被reject。调大该参数只是增加bulk线程池等待队列的大小，减少被reject的概率，并不会提高bulk速度。
   9. indices.breaker.total.limit
   父熔断器，由fielddata、request、inflight等对内存占用的总和来触发，默认上述内存占用超过70%抛出熔断异常
   ES会预先估算一个请求将占用的内存大小，如果请求将占用的内存总大小超过该阈值，则会拒绝该请求。通过设置该阈值参数，可以限制业务请求占用过大内存。
   10. indices.breaker.fielddata.limit
   fielddata内存熔断阈值
   ES会预先估算一个请求将占用的内存大小，如果请求中的fielddata部分占用的内存超过该阈值，则会拒绝该请求。通过设置该参数，可以限制业务请求占用大量的堆内存，该参数应设置为小于等于indices.fielddata.cache.size。
   11. network.breaker.inflight_requests.overhead
   inflight_requests熔断器可以限制当前活动正在处理的请求的内存使用。该参数表示一个系数，所有正在处理的请求估算值将乘以这个系数。将其设置为2，是考虑到request body在安全模块和内核代码中要占用同样大小的内存。
   12. indices.fielddata.cache.size
   分配给fielddata使用的堆内存
   该部分内存不会被JVM垃圾回收，也就是说如果该部分内存满了，会采取淘汰机制将新的数据加载进来，但这部分内存的总大小不变。限制这部分内存的使用，保证足够的堆内存进行业务处理。
   13. TOKEN_VALIDITY
   token有效期
   ES进行Kerberos安全认证的token有效期默认值为10小时，过期后可能导致签名无效，导致业务失败。
   14. cluster.routing.use_adaptive_replica_selection
   动态选取查询性能最优的分片
   开启自适应副本选择允许协调节点根据多个条件将请求发送到被认为“最佳”的副本：
   协调节点与包含数据副本的节点之间的过去请求的响应时间
   在包含数据的节点上执行搜索请求所花费的时间
   包含数据的节点上搜索线程池的队列大小