Elasticsearch参数调优

发布时间:2021-05-18 15:47:29编辑:admin阅读(3401)

    一、概述

    为了避免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


关键字