Elasticsearch集群优化

最新推荐文章于 2024-06-18 14:19:19 发布

要加油呀

最新推荐文章于 2024-06-18 14:19:19 发布

阅读量1.9k

点赞数 2

分类专栏： elk 文章标签： elasticsearch es调优

本文链接：https://blog.csdn.net/weixin_45112997/article/details/130365823

版权

elk 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

Elasticsearch集群优化

版本配置：

ES版本：7.16.1

OS内存64G。

1、磁盘选择

Elasticsearch重度使用磁盘，磁盘的效率越高，Elasticsearch的执行效率就越高。
优化磁盘：
1）使用SSD（固态硬盘）。
2）使用RAID0模式，即将连续的数据分散到多个硬盘存储，这样可以并行进行IO操作。代价是一块硬盘发生故障就会引发系统故障。
3）不要使用远程挂载的存储。即在ES服务器中，而非ES服务器之外的存储。

2、分片策略

每个分片的底层都是一个Lucene索引，会消耗一定的系统资源。搜索请求需要命中索引中的所有分片，分片过多会降低搜索的性能。

分片原则：
1）每个分片占用的磁盘容量不超过ES的JVM的最大堆空间设置（一般设置不超过32G）。
2）分片数一般不超过节点数的三倍。
3）推迟分片分配：节点中断后集群会重新分配分片。但默认集群会等待一分钟来查看节点是否重新加入。可以设置等待的时长，减少分配的次数。

PUT /product/_settings
{
  "settings":{
    "index.unassigned.node_left.delayed_timeout": "5m"
   }
}

减少副本数量：进行写入操作时，需要把写入的数据都同步到副本中，副本越多写入的效率就越慢。进行大批量写入操作时可以先设置副本数为0，写入完成后再修改回正常的状态。

3、内存设置

如果是64G的，建议设置31G

ES默认占用内存时4G，可以修改config/jvm.option文件设置ES的堆内存大小。
1）Xms表示堆内存的初始大小，Xmx表示可分配的最大内存。
2）Xmx和Xms的大小设置为相同时，可以减轻伸缩堆大小带来的压力。
3）Xmx和Xms不要超过物理内存的50%，因为ES内部的Lucene也要占据一部分物理内存。
4）Xmx和Xms不要超过32G，由于JAVA语言的特性，堆内存超过32G会浪费大量系统资源，所以在内存足够的情况下，最终都会采用设置为31G。

4.禁止内存交换：

修改/etc/sysctl.conf 中
- vm.swappiness = 1
elasticsearch.yml中，设置这个：
- bootstrap.mlockall：true

5.修改ES启动用户可使用的系统文件句柄数等。

6.节点分开部署：

master、data、coordinate

7.冷热分离架构：

热数据SSD存储，冷数据普通硬盘存储。

二、合理的Index Mapping：

1.特殊字段：如Boolean、IP、时间等。

2.字符串：

尽量使用keyword，默认的text会被analyze。keyword最大32766字节。在仅查询的情况下，如果有 range 查询需求，使用 numeric，否则使用 keyword。

3.调整refresh间隔：

refresh_interval: 30s，默认的1秒会导致大量segment产生，影响性能。
PUT /my_logs/_settings { “refresh_interval”: “30s” }

4.调整translog刷新机制为异步：

“index”: {

“translog”: {

“flush_threshold_size”: “512mb”, （默认512M，不建议修改）

“sync_interval”: “30s”, (默认5s，可适当增大)

“durability”: “async” （默认request，每次更新都会写trans log，修改为异步）

}

5.Segment的排序方式

创建新索引时，可以配置每个分片中的Segment的排序方式，index sorting是优化检索性能的非常重要的方式之一：

{
“settings” : {
“index” : {
“sort.field” : “date”,
“sort.order” : “desc”
}
},
“mappings”: {
“properties”: {
“date”: {
“type”: “date”
}
}
}
}

三、ES参数调整：

针对data节点，设置elasticsearch.yml中：

thread_pool.bulk.queue_size: 1024 （增大）
indices.fielddata.cache.size: 1gb （默认10%，可适当调小）
indices.queries.cache.size: 1gb（默认10%，可适当调小）
indices.memory.index_buffer_size: 15% （默认10%，会影响写入性能，写入的分片数更多，则需要更多的buffer）
cluster.routing.allocation.disk.include_relocations: false （加快shard分配，在建索引的时候，不考虑迁移的任务）

熔断circuit-breaker调整（调低，减小OOM风险）：

indices.breaker.total.limit: 50%
indices.breaker.request.limit: 10%
indices.breaker.fielddata.limit: 10%
cluster.routing.allocation.same_shard.host：true

如果机器具有128 GB的RAM，可以运行两个节点，每个节点配置31GB内存，Lucene将使用剩余64GB内存。如果这样搭建data节点，在配置中设置cluster.routing.allocation.same_shard.host为true。这将阻止主副本分片被分配到同一台物理机，提高可用性。

四、设置合理的分片数和副本数：

1.对于数据量较小（100GB以下）的index：一般设置3~5个shard

2.对于数据量较大（100GB以上）的index：一般把单个shard的数据量控制在20GB~40GB

3.对于30G内存的节点，shard数量最好控制在600个（即每1GB内存的shard数在20以内）

4.副本数：一般副本数为1，对数据可用性有高要求的，可以设置为2

五、索引管理、段合并（Segment Merge）

1.基于数据大小和保存时长，按天、周、月、年去创建、关闭、删除索引。

2.索引太多时，索引预创建：每天定时任务把明天需要的索引先创建好（从6.7版本开始kibana自带索引生命周期管理ILM）。

3.关闭索引（文件仍然存在于磁盘，只是释放掉内存），需要的时候可以重新打开。

4.通过_forcemerge API进行合并，减少segments数量，同时提高查询效率：max_num_segments取值为：max_num_segments =（单个索引的大小G/分片数/2G）

5.通过_reindex API将历史小索引合并成大索引，减少索引数和分片数。

6.数据roll up（预聚合，物化视图）

六、写入：

写入调优主要从索引，集群trandlog参数配置入手优化。
索引创建默认分配5个分片，1副本。但是并不建议用默认参数。

1、分片大小优化：

根据自己的数据量评估总分片，分片数=数据量G/30G。

2、副本个数：

可以通过写入时副本=0关闭主从复制提高写入速率，写完再设置合适副本

3、bulk写入优化：

采用bulk写入,线程数默认是服务器线程数+1。批大小建议5-15M，从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。报EsRejectedExecutionException达到写入极限。也可通过观察iostat 、 top 看节点资源瓶颈。

4、translog优化，降低io和segment频率。

提高 translog flush：减少刷盘操作，降低IO压力
index.translog.flush_threshold_size: 1024mb
index.translog.flush_threshold_period: 120m

5、设置合适的mapping

避免不必要的字段开启index、source，all。source会存储原始文档，all用于全文搜索会占用资源（关闭可节省40%的资源）。

6、集群参数优化

index.refresh_interval：控制数据可被搜索的时间，同时也会控制生成的segment段数。时间太短会生成太多的段占用io和cpu去合并，影响写入速度。如果对实时性要求不高，可以适当提高采用延迟写入的策略，比如120S。

thread_pool.bulk.queue_size:1000 写入线程队列大小，默认200，线程池参数只用调优这一个。

7、存储优化

磁盘采用ssd固态硬盘，阵列模式使用raid0来避免数据复制提升性能

使用多块硬盘，并通过多个 path.data 目录配置把数据分配到它们上面

8、segment段合并

max_num_segments =1

段合并的计算量庞大，而且还要吃掉大量磁盘 I/O。
有时候合并会拖累写入速率。如果这个真的发生了，Elasticsearch 会自动限制索引（写入）请求到单个线程里。这个可以防止出现段爆炸问题，即数以百计的段在被合并之前就生成出来。如果 Elasticsearch 发现合并拖累索引写入了，它集群日志中会记录一个INFO 级别 now throttling indexing 的信息。

七、查询：

尽量使用filter而不是query。使用filter不会计算评分score，只计算匹配。
如果不关心文档返回的顺序，则按_doc排序。
避免通配符查询。
不要获取太大的结果数据集，如果需要大量数据使用scroll API。

分页查询使用：from+size
遍历使用：scroll
并行遍历使用：scroll+slice

关于数据聚合去重

terms 指定字段聚合 + topN：合理设置聚合的topN，聚合结果是不精确的，是取每个分片的Top size元素后综合排序后的值。
ES5以后的新特性collapse：按某个字段进行“折叠”，这个collapse只针对query出来的结果，只能用在keyword或者numeric类型。
ES6以后支持分页的聚合：Composite Aggregation，可以获取全量的聚合数据，只能用于Terms、Histogram、Date histogram、GeoTile grid。

indices索引参数调优

indices.queries.cache.size：控制过滤器缓存的内存大小（在使用filter过滤时候会用到）。接受百分比值（如5%）或精确值（如）512mb。默认为10%.每个节点上的配置。
index.queries.cache.enabled设置单个索引的是否开启缓存配置。接受true（默认）或 false。
indices.fielddata.cache.size：30% 或具体值10GB来。在聚类或排序时，field data cache会使用频繁
进行segment段合并，减少扫描时间

默认写入合并时=1G会停止合并。写入完成后可以通过定时任务去强制合并，减小segment数据，提高查询速度。
查询条件优化

采用filter过滤器查询提高效率，减少返回的数据量，es不适合返回大数据量，默认10000
禁用source返回。将 _source 设置为 false。
filter的查询速度比query快很多，query会对doc计算score并进行排序
{
“_source”: false,
“query”: { }
}