Elasticsearch参数调优

发布时间：2021-05-18 15:47:29编辑：admin阅读（3484）

一、概述

为了避免Elasticsearch性能不足，需要对默认参数做一些优化。

本文采用elasticsearch:7.10.1，切勿低于7.x版本。

 

二、系统层面调优

系统层面的调优主要是内存的设定与避免交换内存。

ES 安装后默认设置的堆内存是 1GB，这很明显是不够的，那么接下来就会有一个问题出现：我们要设置多少内存给 ES 呢？

其实这是要看我们集群节点的内存大小，还取决于我们是否在服务器节点上还是否要部署其他服务。

• 如果内存相对很大，如 64G 及以上，并且我们不在 ES 集群上部署其他服务，那么我建议 ES 内存可以设置为 31G-32G，因为这里有一个 32G 性能瓶颈问题，直白的说就是即使你给了 ES 集群大于 32G 的内存，其性能也不一定会更加优良，甚至会不如设置为 31G-32G 时候的性能。

• 以我调优的集群为例，我所调优的服务器节点内存为 64G，服务器节点上也基本不跑其他服务，所以我把 ES 集群内存大小设置为了 31G，以充分发挥集群性能。

• 设置 ES 集群内存的时候，还有一点就是确保堆内存最小值（Xms）与最大值（Xmx）的大小是相同的，防止程序在运行时改变堆内存大小，这是一个很耗系统资源的过程。

• 还有一点就是避免交换内存，在操作系统层面进行关闭内存交换。

 

三、分配与副本

• 分片 (shard)：ES 是一个分布式的搜索引擎, 索引通常都会分解成不同部分, 分布在不同节点的部分数据就是分片。ES 自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节。创建索引时默认的分片数为 5 个，并且一旦创建不能更改。

• 副本 (replica)：ES 默认创建一份副本，就是说在 5 个主分片的基础上，每个主分片都相应的有一个副本分片。额外的副本有利有弊，有副本可以有更强的故障恢复能力，但也占了相应副本倍数的磁盘空间。

那我们在创建索引的时候，应该创建多少个分片与副本数呢？

• 对于副本数，比较好确定，可以根据我们集群节点的多少与我们的存储空间决定，我们的集群服务器多，并且有足够大多存储空间，可以多设置副本数，一般是 1-3 个副本数，如果集群服务器相对较少并且存储空间没有那么宽松，则可以只设定一份副本以保证容灾（副本数可以动态调整）。

• 对于分片数，是比较难确定的。因为一个索引分片数一旦确定，就不能更改，所以我们在创建索引前，要充分的考虑到，以后我们创建的索引所存储的数据量，否则创建了不合适的分片数，会对我们的性能造成很大的影响。

 

四、参数调优

elasticsearch.yml中增加如下设置

# 参数优化#######################################
indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

# Search pool
thread_pool.search.size: 5

indices.fielddata.cache.size: 40%

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s




注意：我在参考文章的基础上，删除了一些参数。否则启动会报错，提示无效参数。 

 

索引优化

PUT /_template/elk
{
      "order": 6,
      "template": "logstash-*",    #这里配置模板匹配的Index名称
      "settings": {
        "number_of_replicas" : 1,    #副本数
        "number_of_shards" :   3,    #分片数
         "refresh_interval": "30s",
         "index.translog.durability": "async",
        "index.translog.sync_interval": "30s"

      }
}




 

elasticsearch.yml优化参数详解

Indexing 缓冲大小

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

已经索引好的文档会先存放在内存缓存中，等待被写到到段(segment)中。缓存满的时候会触发段刷盘(吃i/o和cpu的操作)。默认最小缓存大小为48m，不太够，最大为堆内存的10%。对于大量写入的场景也显得有点小。

 

搜索线程池大小

thread_pool.search.size: 5

用于计数/搜索/建议操作。线程池类型是固定的自动队列大小，大小为int类型，初始队列大小为1000。

计算公式：（（cpu个数 * 3）/2）+1

 

设置filedata cache大小

indices.fielddata.cache.size: 40%

filedata cache的使用场景是一些聚合操作(包括排序),构建filedata cache是个相对昂贵的操作。所以尽量能让他保留在内存中

然后日志场景聚合操作比较少，绝大多数也集中在半夜，所以限制了这个值的大小，默认是不受限制的，很可能占用过多的堆内存

 

设置节点之间的故障检测配置

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

参数解释

discovery.zen.fd.ping_interval 节点被 ping 的频率，检测节点是否存活
discovery.zen.fd.ping_timeout 节点存活响应的时间，默认为 30s，如果网络可能存在隐患，可以适当调大
discovery.zen.fd.ping_retries ping 失败/超时多少导致节点被视为失败，默认为 3

 

大数量写入的场景，会占用大量的网络带宽，很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁（1s检测一次）

此项配置将大大缓解节点间的超时问题

 

索引优化参数详解

副本数为1,需要查询性能高可以设置为1。副本太多会占用磁盘，一般设置为1。

"number_of_replicas" : 1

 

#分片数为3，一般有多少个节点，设置多少个分片。

"number_of_shards" :   3

 

这个参数的意思是数据写入后几秒可以被搜索到，默认是 1s。每次索引的 refresh 会产生一个新的 lucene 段, 这会导致频繁的合并行为，如果业务需求对实时性要求没那么高，可以将此参数调大，实际调优告诉我，该参数确实很给力，cpu 使用率直线下降。

"refresh_interval": "30s",

 

这个可以异步写硬盘，增大写的速度

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

 

sync间隔调高

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

 

 

本文参考链接：

https://blog.csdn.net/wmj2004/article/details/80804411

https://blog.csdn.net/lijingjingchn/article/details/104502256

关键字：