石狮市住房和城乡建设局网站,公众号小程序商店,平面设计学院,快速搭建网站的方法背景
基于elasticsearch-5.6.0 机器配置#xff1a;3个云ecs节点#xff0c;16G,4核#xff0c;机械硬盘 优化前#xff0c;写入速度平均3000条/s#xff0c;一遇到压测#xff0c;写入速度骤降#xff0c;甚至es直接频率gc、oom等#xff1b;优化后#xff0c;写入速…背景
基于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: 300indices.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,需要查询性能高可以设置为1number_of_shards : 6, #分片数为6, 副本为1时可以设置成5refresh_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构建流程是怎样的为什么要用filedatawhat、how、why
1.设置节点之间的故障检测配置例如以下elasticsearch.yml配置
discovery.zen.fd.ping_timeout: 120s discovery.zen.fd.ping_retries: 6 discovery.zen.fd.ping_interval: 30s
大数量写入的场景会占用大量的网络带宽很可能使节点之间的心跳超时。并且默认的心跳间隔也相对过于频繁1s检测一次
此项配置将大大缓解节点间的超时问题
后记
这里仅仅是记录对我们实际写入有提升的一些配置项没有针对个别配置项做深入研究。 ———————————————— 版权声明本文为CSDN博主「Java技术栈」的原创文章遵循CC 4.0 BY-SA版权协议转载请附上原文出处链接及本声明。 原文链接https://blog.csdn.net/youanyyou/article/details/124756263
