发布时间: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" } }
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
上一篇: docker 部署Elasticsearch-权限认证(单节点)
下一篇: Sentry异常捕获平台
47569
45926
36869
34433
29043
25681
24530
19685
19205
17717
5542°
6119°
5653°
5708°
6663°
5450°
5454°
5961°
5934°
7265°