分布式系统—ELK优化之Elasticsearch

目录

一、ELK优化

二、优化 ES 索引设置 

1.优化 fsync

2.优化 refresh

3.优化 merge

4.优化设置 

关闭索引

打开索引

打开索引

三、优化线程池配置

1.优化的方案

2.修改 elasticsearch.yml 文件增加配置 

四、锁定内存，不让 JVM 使用 Swap

1.三种方式可以实现 ES 不使用 Swap 分区

1.1.Linux 系统中的关闭 Swap (临时有效)

1.2.Linux 系统中的尽可能减少 Swap 的使用(永久有效)

1.3.启用 bootstrap.memory_lock

五.减少分片数和副本数

1.分片

2.副本数

六、优化总结

对索引进行优化

---

一、ELK优化

ELK优化可以围绕着 linux内核优化、JVM优化、ES配置优化、架构优化（filebeat/fluentd代替

logstash、加入kafka做消息队列）来实现。

ES 作为日志存储时的特性是：高并发写、读少、接受 30 秒内的延时、可容忍部分日志数据丢失

二、优化 ES 索引设置 

1.优化 fsync

为了保证不丢失数据，就要保护 translog 文件的安全

Elasticsearch 2.0 之后，每次写请求(如 index 、delete、update、bulk 等)完成时，都会触发fsync

将 translog 中的 segment 刷到磁盘，然后才会返回 200 OK 的响应；或者: 默认每隔5s就将

translog 中的数据通过fsync强制刷新到磁盘。

该方式提高数据安全性的同时，降低了一点性能

==> 频繁地执行 fsync 操作，可能会产生阻塞导致部分操作耗时较久。 如果允许部分数据丢失，

可设置异步刷新 translog 来提高效率，还有降低 flush 的阀值， 优化如下

"index.translog.durability": "async",
"index.translog.flush_threshold_size":"1024mb",
"index.translog.sync_interval": "120s"
 

2.优化 refresh

写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成

Lucene 的完整 segment 后，才可以被搜索

默认 1 秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影

响。所以，加大时长可以降低系统开销。 对于日志搜索来说，实时性要求不是那么高，设置为 5

秒或者 10s；对于 SkyWalking，实时性要求更低一些，我们可以设置为 30s

设置如下

"index.refresh_interval":"5s"

 

3.优化 merge

index.merge.scheduler.max_thread_count 控制并发的 merge 线程数，如果存储是并发性能较

好的 SSD，可以用系统默认的 max(1, min(4, availableProcessors / 2))，当节点配置的 cpu 核数

较高时，merge 占用的资源可能会偏高，影响集群的性能，普通磁盘的话设为1，发生磁盘 IO 堵

塞。设置 max_thread_count 后，会有 max_thread_count + 2 个线程同时进行磁盘操作，也就是

设置为 1 允许 3 个线程

设置如下

"index.merge.scheduler.max_thread_count":"1"

4.优化设置 

需要先 close 索引，然后再执行，最后成功之后再打开

关闭索引

curl -XPOST 'http://localhost:9200/_all/_close'

打开索引

curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preser

打开索引

curl -XPOST 'http://localhost:9200/_all/_open'

 

三、优化线程池配置

• write 线程池满负荷，导致拒绝任务，而有的数据无法写入。而经过上面的优化后，拒绝的情况少了很多，但是还是有拒绝任务的情况。所以我们还需要优化 write 线程池
• write 线程池采用 fixed 类型的线程池，也就是核心线程数与最大线程数值相同。线程数默认等于 cpu 核数，可设置的最大值只能是 cpu 核数加 1，比如 16 核的 CPU， 能设置的线程数最大值为 17

1.优化的方案

• 线程数改为 17，也就是 cpu 总核数加 1
• 队列容量加大。队列在此时的作用是消峰。不过队列容量加大本身不会提升处理速度，只是起到缓冲作用。此外，队列容量也不能太大，否则积压很多任务时会占用过多堆内存

2.修改 elasticsearch.yml 文件增加配置 

# 线程数设置
thread_pool:
  write:
    # 线程数默认等于cpu核数，即16  
    size: 17
    # 因为任务多时存在任务拒绝的情况，所以加大队列大小，可以在间歇性任务量陡增的情况下，缓存任务在队列，等高峰过去逐步消费完。
    queue_size: 10000

四、锁定内存，不让 JVM 使用 Swap

• Swap交换分区：当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到 Swap 中，等到那些程序要运行时，再从 Swap 中恢复保存的数据到内存中。这样，系统总是在物理内存不够时，才进行 Swap 交换
• Swap 交换分区对性能和节点稳定性非常不利，一定要禁用。它会导致垃圾回收持续几分钟而不是几毫秒，并会导致节点响应缓慢，甚至与集群断开连接

1.三种方式可以实现 ES 不使用 Swap 分区

1.1.Linux 系统中的关闭 Swap (临时有效)

执行命令

sudo swapoff -a

可以临时禁用 Swap 内存，但是操作系统重启后失效

1.2.Linux 系统中的尽可能减少 Swap 的使用(永久有效)

执行下列命令

echo "vm.swappiness = 1" >> /etc/sysctl.conf

 

正常情况下不会使用 Swap，除非紧急情况下才会 Swap

1.3.启用 bootstrap.memory_lock

config/elasticsearch.yml 文件增加配置
#锁定内存，不让 JVM 写入 Swap，避免降低 ES 的性能
bootstrap.memory_lock: true

五.减少分片数和副本数

1.分片

索引的大小取决于分片与段的大小，分片过小，可能导致段过小，进而导致开销增加；分片过大可

能导致分片频繁 Merge，产生大量 IO 操作，影响写入性能

因为我们每个索引的大小在 15G 以下，而默认是 5 个分片，没有必要这么多，所以调整为 3 个

"index.number_of_shards": "3"

2.副本数

减少集群副本分片数，过多副本会导致 ES 内部写扩大。副本数默认为 1，如果某索引所在的 1 个

节点宕机，拥有副本的另一台机器拥有索引备份数据，可以让索引数据正常使用。但是数据写入副

本会影响写入性能。对于日志数据，有 1 个副本即可。 对于大数据量的索引，可以设置副本数为

0，减少对性能的影响

"index.number_of_replicas": "1"

六、优化总结

对索引进行优化

• 优化fsync，适当加大刷盘间隔时间（index.translog.sync_interval，默认值为5s，可调整为30s或60s）
• 优化refresh，适当加大把内存数据写入Lucene的间隔时间（index.refresh_interval，默认值为1s，可调整为5s或10s）
• 优化merge，根据硬盘的性能适当调整merge的线程数（index.merge.scheduler.max_thread_count，默认值为max，可调整为1，设置为1可允许最多3个并发的merge线程数）

• 优化write线程池配置，减少拒绝任务的情况

1. 修改ES配置文件elasticsearch.yml，设置write线程为 CPU核数+1 

• 锁定内存，不让ES使用swap

1. swapoff -a ，关闭swap
2. 修改内核参数 vm.swappiness=1，使系统尽量不使用swap
3. 修改ES配置文件：bootstrap.memory_lock: true ，启动ES锁定内存

• 适当的减少索引的分片数、副本数

1. 分片数：index.number_of_shards，默认值为5，索引大小较小时，可调整分片数为3
2. 副本数：index.number_of_replicas，默认值为1，即每个索引会有一份额外的副本数据，对于日志数据不需要太高的安全性，有1个副本即可，所以可调整副本数为0