目录
1.ELK优化
2.优化 ES 索引设置
2.1 优化 fsync
2.2 优化 refresh
2.3 优化 merge
2.4 优化设置
2.5 打开索引
3.优化线程池配置
3.1 优化的方案
4.锁定内存，不让 JVM 使用 Swap
5.减少分片数、副本数
6.ES优化总结
1.ELK优化
ELK优化可以围绕着 linux内核优化、JVM优化、ES配置优化、架构优化（filebeat/fluentd代替logstash、加入kafka做消息队列）来实现。
ES 作为日志存储时的特性是：高并发写、读少、接受 30 秒内的延时、可容忍部分日志数据丢失。
2.优化 ES 索引设置
2.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.2 优化 refresh
写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。
默认 1 秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。 对于日志搜索来说，实时性要求不是那么高，设置为 5 秒或者 10s；对于 SkyWalking，实时性要求更低一些，我们可以设置为 30s。
设置如下：
"index.refresh_interval":"5s
2.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"
2.4 优化设置
# 需要先 close 索引，然后再执行，最后成功之后再打开
# 关闭索引
curl -XPOST 'http://localhost:9200/_all/_close'# 修改索引设置
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{"index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "10s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}'
2.5 打开索引
curl -XPOST 'http://localhost:9200/_all/_open'
3.优化线程池配置
- write 线程池满负荷，导致拒绝任务，而有的数据无法写入。而经过上面的优化后，拒绝的情况少了很多，但是还是有拒绝任务的情况。所以我们还需要优化 write 线程池。
- write 线程池采用 fixed 类型的线程池，也就是核心线程数与最大线程数值相同。线程数默认等于 cpu 核数，可设置的最大值只能是 cpu 核数加 1，比如 16 核的 CPU， 能设置的线程数最大值为 17。
3.1 优化的方案
●线程数改为 17，也就是 cpu 总核数加 1
●队列容量加大。队列在此时的作用是消峰。不过队列容量加大本身不会提升处理速度，只是起到缓冲作用。此外，队列容量也不能太大，否则积压很多任务时会占用过多堆内存。修改 elasticsearch.yml 文件增加配置
# 线程数设置
thread_pool:
write:
# 线程数默认等于cpu核数，即16
size: 17
# 因为任务多时存在任务拒绝的情况，所以加大队列大小，可以在间歇性任务量陡增的情况下，缓存任务在队列，等高峰过去逐步消费完。
queue_size: 10000
4.锁定内存，不让 JVM 使用 Swap
- Swap交换分区：当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到 Swap 中，等到那些程序要运行时，再从 Swap 中恢复保存的数据到内存中。这样，系统总是在物理内存不够时，才进行 Swap 交换。
- Swap 交换分区对性能和节点稳定性非常不利，一定要禁用。它会导致垃圾回收持续几分钟而不是几毫秒，并会导致节点响应缓慢，甚至与集群断开连接。
有三种方式可以实现 ES 不使用 Swap 分区
（1）Linux 系统中的关闭 Swap (临时有效)
执行命令 sudo swapoff -a
可以临时禁用 Swap 内存，但是操作系统重启后失效
（2）Linux 系统中的尽可能减少 Swap 的使用(永久有效)
执行下列命令
echo "vm.swappiness = 1" >> /etc/sysctl.conf
正常情况下不会使用 Swap，除非紧急情况下才会 Swap。
（3）启用 bootstrap.memory_lock
config/elasticsearch.yml 文件增加配置
#锁定内存，不让 JVM 写入 Swap，避免降低 ES 的性能
bootstrap.memory_lock: true
5.减少分片数、副本数
（1）分片
索引的大小取决于分片与段的大小，分片过小，可能导致段过小，进而导致开销增加；分片过大可能导致分片频繁 Merge，产生大量 IO 操作，影响写入性能。
因为我们每个索引的大小在 15G 以下，而默认是 5 个分片，没有必要这么多，所以调整为 3 个。
"index.number_of_shards": "3"
（2）副本数
减少集群副本分片数，过多副本会导致 ES 内部写扩大。副本数默认为 1，如果某索引所在的 1 个节点宕机，拥有副本的另一台机器拥有索引备份数据，可以让索引数据正常使用。但是数据写入副本会影响写入性能。对于日志数据，有 1 个副本即可。 对于大数据量的索引，可以设置副本数为 0，减少对性能的影响。
"index.number_of_replicas": "1"
6.ES优化总结
(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线程数）
(2）优化write线程池配置，减少拒绝任务的情况：修改ES配置文件elasticsearch.yml，设置write线程为 CPU核数+1
(3）锁定内存，不让ES使用swap：swapoff -a ，关闭swap
修改内核参数 vm.swappiness=1，使系统尽量不使用swap
修改ES配置文件：bootstrap.memory_lock: true ，启动ES锁定内存
(4）适当的减少索引的分片数、副本数
分片数：index.number_of_shards，默认值为5，索引大小较小时，可调整分片数为3
副本数：index.number_of_replicas，默认值为1，即每个索引会有一份额外的副本数据，对于日志数据不需要太高的安全性，有1个副本即可，所以可调整副本数为0
