ElasticSeach性能调优

1. 硬件相关

1.1 硬盘

1. 一块好的硬盘，会带来ES整体性能10倍以上提升，推荐在datanode节点上使用SSD硬盘，索引的data目录，存放在SSD硬盘上。

1.2 内存

1. 建议内存>128G时，ES使用的JVM内存为30G，lucene会消耗大量的cache，如果索引文件很大，建议预留足够多的cache给lucene使用；
2. 如果内存<64G时，需要综合考虑单节点上索引文件的大小来评估，如果索引文件较大，建议ES JVM内存配置为16G，留下足够的内存给cache使用；

2. 操作系统相关

2.1 调整磁盘参数

• 磁盘blockdev参数的readbuffer，建议调整为32

可以通过命令 blockdev --getra /dev/vdb 查看，需要sudo权限，通过命令 blockdev --setra 32 /dev/vdb 进行调整；

3. ES相关

3.1 集群相关

1. 检查集群单个datanode节点的负载情况
• 可以通过命令 GET _cat/nodes?v 来查看，重点关注各个节点的 heap.percent和ram.percent指标；
• heap.percent表示ES使用的JVM内存情况，该值应该低于75，如果长时间大于75，表示JVM内存配置不够，如果JVM已经配置到30G，则表示该Datanode节点上的压力较大，需要考虑增加Datanode节点来分摊压力；
• ram.percent 表示机器上内存的使用情况，实际对应linux上的 used+cache内存使用情况，如果该值接近100%，则表示机器上cache内存不够用，主要是由于ES检索中，lucene会消耗大量cache内存，如果cache不够，会导致lucene无法将部分文件加载到cache中，会频繁从磁盘中进行读取，导致查询延时加大；
2. 检查集群上各个节点上的shard分布情况
• 可以通过命令 GET _cat/shards?v 来查看，重点关注单个datanode上的shard数量，以及shard的总大小；

建议解决方案

• 如果datanode节点的压力过载，那就要设法降低datanode节点上的压力，主要是要降低节点上活跃的shard数量
• 评估索引是否在使用，关闭不用的索引
• 评估索引的副本数是否合理，降低副本数
• 如果只有部分datanode节点压力过载，可能原因是这些节点上的索引数据量较大，并且较为活跃，可以手工移动shard到其他压力相对较小的datanode上，注意手工调整前，需要先关闭集群的分片自动分配机制，调整完成后再打开；

3.2 索引相关

1. 检查索引分片数
• 索引分片数不是越少越好，也不是越多越好，需要结合索引文件的大小，并发写入、查询的性能要求，进行调优，在分片数和性能之间达到一个平衡即可；
• ES官方建议，一个分片的大小在10-40G之间，具体要结合索引的mapping复杂度来进行实际调优；
• 索引的分片数，是在索引创建的时候设置的，无法进行动态调整，如果要调整，需要通过新建索引，然后将旧索引的数据，通过reindex命令迁移到新索引中来进行；
2. 检查索引副本数
• 副本数不是越多越好，副本存在的意义，最主要是保障数据的可靠性，另外可以提升查询QPS，但是也会给集群带来翻倍的资源消耗；
• 建议在性能满足要求的情况下，谨慎增加副本数，没有没有特殊场景，使用默认的副本数1即可；
• 参考命令

curl -XPUT "http://127.0.0.1:9200/{index-name}/_settings" -H "Content-Type: application/json" -d '{

  "number_of_replicas"
: 0

 }'

1. 调整refreshtime参数
• refreshtime主要用于索引有写入场景时，写入的数据多久可以被检索到，refreshtime默认为1s，表示数据通过bulk接口写入后，最多1s后数据可以被写入到cache中（不是磁盘），然后就可以被检索到；
• 如果ES仅用于检索，没有写入场景，则可以将refreshtime设置为-1；
• 如果ES有写入场景，但是对检索实时性要求不高，可以将refreshtime设置为一个较大的值，比如60s；
• 参考命令

curl -XPUT
"http://127.0.0.1:9200/{index-name}/_settings" -H "Content-Type:
application/json" -d '{

  "refresh_interval": "60s"

 }'

1. 调整translog参数
• translog存在的意义，是为了保证数据可靠性，当新写入的数据通过refresh刷新到cache，还没有写到磁盘时，如果发生丢失，可以从translog中进行恢复，ES中默认每30分钟进行一次flush操作，或者当translog的数据达到某个上限的时候会进行一次flush操作；
• 而translog的可靠性如何保证呢，ES中默认是每5s将synclog写入磁盘，将这个间隔 index.translog.sync_interval 调大，可以减少磁盘IO的次数；另外，也可以适当调大translog文件多大时会自动写入磁盘的阈值，目的也是为了减少磁盘IO次数；
• 参考命令

curl -XPUT
"http://127.0.0.1:9200/index/_settings?pretty" -d '{

  "index.translog.durability": "async",

  "index.translog.flush_threshold_size": "1gb",

  "index.translog.sync_interval": "30s"

 }

• curl -XPUT
  '192.168.2.181:9200/index/_settings?pretty' -H "Content-Type:
  application/json" -d '{
  
    "index.translog.durability": "async",
  
    "index.translog.flush_threshold_size": "1gb",
  
    "index.translog.sync_interval": "30s"
  
   }

1. 检查segment参数
• segment表示shard中的分段，ES中每次flush，会生成一个segment，然后再通过专门的merge线程，对segment进行merge，在检索时，ES会依次去每个segment检索，segment越多，会导致检索效率越低；
• 通过 _cat/shards?v&h=index,shard,prirep,segmentsCount 可以查到shard的segment数量，该值越大，表示shard中存在的分段数量越多，
• 如果索引后续不会再有大规模的写操作，建议可以通过 forcemerge 命令，对segment进行强制合并，可以指定合并后的segment数量， 但是要注意，segment合并操作，会消耗大量的磁盘IO，也会占用两倍于shard大小的磁盘空间，建议在确保磁盘空间足够的情况下，选择闲时进行merge操作；