共计 3083 个字符，预计需要花费 8 分钟才能阅读完成。
背景
- 基于 elasticsearch-5.6.0
- 机器配置：3 个云 ecs 节点，16G,4 核，机械硬盘
优化前，写入速度均匀3000 条 /s，一遇到压测，写入速度骤降，甚至 es 间接频率 gc、oom 等；优化后，写入速度均匀8000 条 /s，遇到压测，能在压测完结后 30 分钟内消化完数据，各项指标回归失常。
生产配置
这里我先把本人优化的后果贴出来，前面有参数的详解：
elasticsearch.yml 中减少如下设置
indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb
# Search pool
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 这个参数慎用！强制批改 cpu 核数，以冲破写线程数限度
# processors: 16
# Bulk pool
#thread_pool.bulk.size: 16
thread_pool.bulk.queue_size: 300
# Index pool
#thread_pool.index.size: 16
thread_pool.index.queue_size: 300
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" : 0, #正本数为 0, 须要查问性能高能够设置为 1
"number_of_shards" : 6, #分片数为 6, 正本为 1 时能够设置成 5
"refresh_interval": "30s",
"index.translog.durability": "async",
"index.translog.sync_interval": "30s"
}
}优化参数详解
精密设置全文域： string 类型字段默认会分词，不仅会额定占用资源，而且会影响创立索引的速度。所以，把不须要分词的字段设置为not_analyzed
禁用_all 字段: 对于日志和 apm 数据，目前没有场景会应用到
正本数量设置为 0: 因为咱们目前日志数据和 apm 数据在 es 只保留最近 7 天的量，全量日志保留在 hadoop，能够依据须要通过 spark 读回到 es – 况且正本数量是能够随时批改的，区别分片数量
应用 es 主动生成 id： es 对于主动生成的 id 有优化，防止了版本查找。因为其生成的 id 是惟一的
设置 index.refresh_interval： 索引刷新距离，默认为 1s。因为不须要如此高的实时性，咱们批改为 30s – 扩大学习：刷新索引到底要做什么事件
设置段合并的线程数量：
curl -XPUT 'your-es-host:9200/nginx_log-2018-03-20/_settings' -d '{"index.merge.scheduler.max_thread_count" : 1}'段合并的计算量宏大，而且还要吃掉大量磁盘 I /O。合并在后盾定期操作，因为他们可能要很长时间能力实现，尤其是比拟大的段
机械磁盘在并发 I / O 反对方面比拟差，所以咱们须要升高每个索引并发拜访磁盘的线程数。这个设置容许 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 容许三个线程
扩大学习：什么是段(segment)？如何合并段？为什么要合并段？（what、how、why）另外，ES 系列面试题和答案全副整顿好了，微信搜寻Java 技术栈，在后盾发送：面试，能够在线浏览。
1. 设置异步刷盘事务日志文件：
"index.translog.durability": "async",
"index.translog.sync_interval": "30s"对于日志场景，可能承受局部数据失落。同时有全量牢靠日志存储在 hadoop，失落了也能够从 hadoop 复原回来
2.elasticsearch.yml 中减少如下设置：
indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb曾经索引好的文档会先寄存在内存缓存中，期待被写到到段 (segment) 中。缓存满的时候会触发段刷盘(吃 i / o 和 cpu 的操作)。默认最小缓存大小为 48m，不太够，最大为堆内存的 10%。对于大量写入的场景也显得有点小。
扩大学习：数据写入流程是怎么样的(具体到如何构建索引)？
1. 设置 index、merge、bulk、search 的线程数和队列数。例如以下 elasticsearch.yml 设置：
# Search pool
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 这个参数慎用！强制批改 cpu 核数，以冲破写线程数限度
# processors: 16
# Bulk pool
thread_pool.bulk.size: 16
thread_pool.bulk.queue_size: 300
# Index pool
thread_pool.index.size: 16
thread_pool.index.queue_size: 3002. 设置 filedata cache 大小，例如以下 elasticsearch.yml 配置：
indices.fielddata.cache.size: 15%filedata cache 的应用场景是一些聚合操作(包含排序), 构建 filedata cache 是个绝对低廉的操作。所以尽量能让他保留在内存中
而后日志场景聚合操作比拟少，绝大多数也集中在中午，所以限度了这个值的大小，默认是不受限制的，很可能占用过多的堆内存
扩大学习：什么是 filedata？构建流程是怎么的？为什么要用 filedata？（what、how、why）
1. 设置节点之间的故障检测配置，例如以下 elasticsearch.yml 配置：
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s大数量写入的场景，会占用大量的网络带宽，很可能使节点之间的心跳超时。并且默认的心跳距离也绝对过于频繁（1s 检测一次）
此项配置将大大缓解节点间的超时问题
后记
这里仅仅是记录对咱们理论写入有晋升的一些配置项，没有针对个别配置项做深入研究。
扩大学习后续填坑。根本都遵循（what、how、why）准则去学习。
版权申明：本文为 CSDN 博主「无影 V 随风」的原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接及本申明。原文链接：https://blog.csdn.net/wmj2004…
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
