Elasticsearch集群调优
文章目录
-
- 一、服务器硬件以及内存调优
-
- 1、调整交换区的swap大小
- 2、调整普通用户打开文件数以及线程数的限制
- 3、调整ES的JVM堆内存大小
- 二、ES的参数调优
-
- 1、集群自动发现机制
- 2、集群的主节点选举
- 3、集群的故障检测
- 4、集群状态更新
- 5、no Master block机制
- 6、增加 Refresh 时间间隔
- 7、综合调优概览
一、服务器硬件以及内存调优
1、调整交换区的swap大小
关闭系统的交换区，禁用linux的虚拟内存，尽量让我们的ES禁用虚拟内存。
- 因为如果使用虚拟内存，就会将内存当中过多的数据缓存到磁盘上面去，可以简单理解为就是拿了一块磁盘出来当做内存使用，这样当然性能就会急剧下降，所以在实际工作当中我们一般的都会尽量关闭linux的交换区的内存空间
- 关闭交换区的空间大小 ：
swapoff -a - 如果不能完全禁用swap交换区的空间大小，我们可以调整设置，尽量减少swap的空间，通过调整交换区内存空间大小，来调整我们的交换比例。
- swappiness参数值可设置范围在0到100之间。 低参数值会让内核尽量少用交换，更高参数值会使内核更多的去使用交换空间。默认值为60。
- vim /etc/sysctl.conf
vm.swappiness=1
- vim /etc/sysctl.conf
- 如果没法更改我们的swap的参数值，那么我们也可以在es当中配置，禁止JVM堆内存当中的数据交换到磁盘当中去
- cd /kkb/install/elasticsearch-6.7.0/config/
vim elasticsearch.yml
bootstrap.memory_lock:true
- cd /kkb/install/elasticsearch-6.7.0/config/
2、调整普通用户打开文件数以及线程数的限制
普通用户打开文件的最大数限制
- ES因为需要大量的创建索引文件，需要大量的打开系统的文件，所以我们需要解除linux系统当中打开文件最大数目的限制，不然ES启动就会抛错
三台机器使用es用户执行以下命令解除打开文件数据的限制
sudo vi /etc/security/limits.conf
* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 4096
普通用户启动线程数限制
三台机器执行以下命令打开文件最大数
sudo vi /etc/sysctl.conf
vm.max_map_count=655360
fs.file-max=655360
执行以下命令生效
sudo sysctl -p
注意：以上两个问题修改完成之后，一定要重新连接linux生效。关闭secureCRT或者XShell工具，然后重新打开工具连接linux即可
3、调整ES的JVM堆内存大小
官方建议ES的堆内存大小不要超过32GB，超过32GB之后，反而会造成大量的内存的浪费，
- 所以我们在ES当中，JVM堆内存大小，尽量调整成小于32GB，
- 其中堆内存大小与系统内存大小，尽量五五分，例如一台服务器64GB，那么我们可以给ES堆内存大小设置为32GB，剩下的32GB留作OS cache ，当做系统内存留给lucene来使用（因为ES底层也是基于lucene的）
- 调整堆内存大小的官方建议
https://www.elastic.co/guide/cn/elasticsearch/guide/current/heap-sizing.html
cd /kkb/install/elasticsearch-6.7.0/config
vim jvm.options
-Xms32g
-Xmx32g
二、ES的参数调优
1、集群自动发现机制
配置ES集群的自动发现机制
discovery.zen.ping.unicast.hosts: ["node01", "node02", "node03"]
配置在每轮ping操作中等待DNS主机名查找的超时时间。需要指定时间单位，默认为5秒。
discovery.zen.ping.unicast.resolve_timeout:30
2、集群的主节点选举
ES集群当中的节点角色介绍
（1） Master
- 主要负责集群中索引的创建、删除以及数据的Rebalance等操作。
- Master不负责数据的索引和检索，所以负载较轻。
- 当Master节点失联或者挂掉的时候，ES集群会自动从其他Master节点选举出一个Leader。
- 为了防止脑裂，常常设置参数为
discovery.zen.minimum_master_nodes=N/2+1，其中N为集群中Master节点的个数。建议集群中Master节点的个数为奇数个，如3个或者5个。
设置为Master节点的方式如下：
node.master: true #设置为主节点
node.data: false #不是数据节点
node.ingest: false #不是ingest 节点
search.remote.connect: false #禁用跨集群查询
（2）Data Node
- 主要负责集群中数据的索引和检索，一般压力比较大。
- 建议和Master节点分开，避免因为Data Node节点出问题影响到Master节点。
设置一个节点为Data Node节点的方式如下：
node.master: false #不是主节点
node.data: true #作为数据二级店
node.ingest: false # 不是ingest节点
search.remote.connect: false #禁用跨集群查询
（3）Coordinating Node
- 协作节点，主要用于协作处理集群当中的一些事情
node.master: false #不是主节点
node.data: true #作为数据二级店
node.ingest: false # 不是ingest节点
search.remote.connect: false #禁用跨集群查询
（4）Ingest Node
- Ingest node专门对索引的文档做预处理，实际中不常用，除非文档在索引之前有大量的预处理工作需要做。
Ingest node设置如下：
node.master: false node.master: false
node.master: false
node.data: false
node.ingest: true
search.remote.connect: false
以上节点当中最重要的就是Master Node，这个节点关系着我们集群的生死存放，我们可以通过设置多个master node作为我们集群当中的主节点，其中多个master node会通过选举机制实现选择一个master node作为active，其他的作为standBy，如果master active状态的主节点宕机，es会从其他的standBy状态的主节点当中重新选择一个新的作为active状态的节点。
控制节点加入某个集群或者开始选举的响应时间(默认3s)discovery.zen.ping_timeout:3
在网络缓慢时，3秒时间可能不够，这种情况下，需要慎重增加超时时间，增加超时时间会减慢选举进程。一旦节点决定加入一个存在的集群，它会发出一个加入请求给主节点，这个请求的超时时间由discovery.zen.join_time控制，默认是 ping 超时时间(discovery.zen.ping_timeout)的20倍。
当主节点停止或者出现问题，集群中的节点会重新 ping 并选举一个新节点。有时一个节点也许会错误的认为主节点已死，所以这种 ping 操作也可以作为部分网络故障的保护性措施。在这种情况下，节点将只从其他节点监听有关当前活动主节点的信息。
如果discovery.zen.master_election.ignore_non_master_pings设置为true时（默认值为false），node.master为false的节点不参加主节点的选举，同时选票也不包含这种节点。
通过设置node.master为false，可以将节点设置为非备选主节点，永远没有机会成为主节点。discovery.zen.minimum_master_nodes设置了最少有多少个备选主节点参加选举，同时也设置了一个主节点需要控制最少多少个备选主节点才能继续保持主节点身份。如果控制的备选主节点少于discovery.zen.minimum_master_nodes个，那么当前主节点下台，重新开始选举。
discovery.zen.minimum_master_nodes必须设置一个恰当的备选主节点值(quonum，一般设置 为备选主节点数/2+1)，尽量避免只有两个备选主节点，因为两个备选主节点quonum应该为2，那么如果一个节点出现问题，另一个节点的同意人数最多只能为1，永远也不能选举出新的主节点，这时就发生了脑裂现象。
3、集群的故障检测
有两个故障检测进程在集群的生命周期中一直运行。一个是主节点的，ping集群中所有的其他节点，检查他们是否活着。另一种是每个节点都ping主节点，确认主节点是否仍在运行或者是否需要重新启动选举程序。
使用discovery.zen.fd前缀设置来控制故障检测过程，配置如下：
| 配置 | 描述 |
|---|---|
| discovery.zen.fd.ping_interval | 节点多久ping一次，默认1s |
| discovery.zen.fd.ping_timeout | 等待响应时间，默认30s |
| discovery.zen.fd.ping_retries | 失败或超时后重试的次数，默认3 |
4、集群状态更新
主节点是唯一一个能够更新集群状态的节点。主节点一次处理一个群集状态更新，应用所需的更改并将更新的群集状态发布到群集中的所有其他节点。当其他节点接收到状态时，先确认收到消息，但是不应用最新状态。如果主节点在规定时间（discovery.zen.commit_timeout ，默认30s）内没有收到大多数节点(discovery.zen.minimum_master_nodes)的确认，集群状态更新不被通过。
一旦足够的节点响应了更新的消息，新的集群状态(cluster state)被提交并且会发送一条消息给所有的节点。这些节点开始在内部应用新的集群状态。在继续处理队列中的下一个更新之前，主节点等待所有节点响应，直到超时(discovery.zen.publish_timeout，默认设置为30秒)。上述两个超时设置都可以通过集群更新设置api动态更改。
5、no Master block机制
对于一个可以正常充分运作的集群来说，必须拥有一个活着的主节点和正常数量(discovery.zen.minimum_master_nodes个)活跃的备选主节点。discovery.zen.no_master_block设置了没有主节点时限制的操作。
它又两个可选参数：
- all：所有操作均不可做，读写、包括集群状态的读写api，例如获得索引配置(index settings)，putMapping，和集群状态(cluster state)api
- write：默认为write，写操作被拒绝执行，基于最后一次已知的正常的集群状态可读，这也许会读取到已过时的数据。
discovery.zen.no_master_block，对于节点相关的基本api，这个参数是无效的，如集群统计信息(cluster stats)，节点信息(node info)，节点统计信息(node stats)。对这些api的请求不会被阻止，并且可以在任何可用节点上运行。
6、增加 Refresh 时间间隔
为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒 （index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。
当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。
同时，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。
7、综合调优概览
ES调优综合参数设置概览：
index.merge.scheduler.max_thread_count:1 # 索引 merge ***线程数
indices.memory.index_buffer_size:30% # 内存
index.translog.durability:async # 这个可以异步写硬盘，增大写的速度
index.translog.sync_interval:120s #translog 间隔时间
discovery.zen.ping_timeout:120s # 心跳超时时间
discovery.zen.fd.ping_interval:120s # 节点检测时间
discovery.zen.fd.ping_timeout:120s #ping 超时时间
discovery.zen.fd.ping_retries:6 # 心跳重试次数
thread_pool.bulk.size:20 # 写入线程个数 由于我们查询线程都是在代码里设定好的，我这里只调节了写入的线程数
thread_pool.bulk.queue_size:1000 # 写入线程队列大小
index.refresh_interval:300s #index 刷新间隔复制代码