当前位置: 首页 > 后端技术 > Java

Elasticsearch写优化,从3000到8000-s,让你的ES飞起来,..

时间:2023-04-01 18:19:58 Java

后台基于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#Searchpoolthread_pool。search.size:5thread_pool.search.queue_size:100#慎用该参数!强行修改cpu核数突破写线程数限制#processors:16#bulkpool#thread_pool.bulk.size:16thread_pool.bulk.queue_size:300#Indexpool#thread_pool.index.size:16thread_pool.index.queue_size:300indices.fielddata.cache.size:40%discovery.zen.fd.ping_timeout:120sdiscovery.zen.fd.ping_retries:6discovery.zen.fd.ping_interval:30s索引优化配置:PUT/_template/elk{"order":6,"template":"logstash-*",#这里配置模板匹配的索引名称"settings":{"number_of_replicas":0,#副本数为0,如果需要高查询性能,可以设置为1"number_of_shards":6,#当分片数为6,副本为1时,可以设置为5"refresh_interval":"30s","index.translog.durability":"异步","index.translog.sync_interval":"30s"}}优化参数详解全文字段精细设置:字符串类型字段默认会分词,不仅占用额外资源,还会影响索引创建速度因此,将不需要分词的字段设置为not_analyzed来禁用_all字段:对于log和apm数据,目前不存在副本数设置为0的场景:因为我们目前只保留最近7天的es中的log数据和apm数据,日志全量保存在hadoop中,可以根据需要传给spark读回es——另外副本数可以随时修改,以区分分片数,使用es自动生成ids:es针对自动生成ids进行了优化,避免了版本查找。因为生成的ids是唯一设置index的。refresh_interval:索引刷新间隔,默认1s。因为这么高的real-时间性能没有要求,我们改成了30s-延伸学习:索引刷新到底是干什么的?设置段合并的线程数:curl-XPUT'your-es-host:9200/nginx_log-2018-03-20/_settings'-d'{"index.merge.scheduler.max_thread_count":1}'数量段合并的计算量很大,同时也消耗大量的磁盘I/O。MergeinPeriodicoperations在后台,因为它们可能需要很长时间才能完成,尤其是比较大的机械盘对并发I/O的支持很差,所以我们需要减少每个索引并发访问磁盘的线程数。这个设置允许max_thread_count+2个线程同时进行磁盘操作,即设置为1允许三个线程展开学习:什么是段?如何合并段?为什么要合并段?(what,how,why)另外,ES系列面试题和答案都整理好了,微信搜索Java技术栈,后台发:面试,可以在线阅读。1、设置异步事务日志文件:"index.translog.durability":"async","index.translog.sync_interval":"30s"对于日志场景,部分数据丢失是可以接受的。同时,hadoop中存储了足量的可靠日志,丢失了可以从hadoop中恢复,在内存缓存中,waits写到segments中。当缓存满时,会触发段刷新(吃掉i/o和cpu操作)。默认的最小缓存大小是48m,不够用,最大是堆内存的10%。对于大量编写的场景,它也显得有点小。延伸学习:数据写入过程是怎样的(具体是如何建立索引)?1.设置索引、合并、批量和搜索的线程数和队列数。例如下面的elasticsearch.yml设置:#Searchpoolthread_pool.search.size:5thread_pool.search.queue_size:100#这个参数慎用!强制修改cpu核数,突破写线程数限制#processors:16#bulkpoolthread_pool.bulk.size:16thread_pool.bulk.queue_size:300#Indexpoolthread_pool.index.size:16thread_pool.index.queue_size:3002.设置filedatacacheSize,比如下面elasticsearch.yml配置:indices.fielddata.cache.size:15%filedatacache的使用场景是一些聚合操作(包括排序),构建filedatacache是??一个比较昂贵的手术。所以尽量保留在内存中,而且日志场景聚合操作比较少,而且大部分都集中在半夜,所以这个值的大小是有限的。默认是unlimited,很可能会占用过多的堆内存。延伸学习:什么是filedata?构建过程是什么样的?为什么要使用文件数据?(what,how,why)1.设置节点间的故障检测配置,比如如下elasticsearch.yml配置:discovery.zen.fd.ping_timeout:120sdiscovery.zen.fd.ping_retries:6discovery.zen.fd.ping_interval:30s写入量大的场景会占用大量网络带宽,可能导致节点间心跳超时。而且默认的心跳间隔相对来说过于频繁了(1s检查一次)。这个配置会大大缓解节点间的超时问题后记这只是记录了一些我们实际写的有提升的配置项,并没有对个别配置项做深入研究。延伸学习,后续填坑。基本上遵循(what、how、why)的原则来学习。版权声明:本文为CSDN博主“无影V随风”原创文章,遵循CC4.0BY-SA版权协议。转载请附上原文出处链接及本声明。