添加URL
相关文章推荐
18330380933  ·  Unable to retrieve ...·  11 月前    · 
1043605696  ·  ElasticSearch Cause: ...·  1 年前    · 
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接: https://blog.csdn.net/wmj2004/article/details/80804411
  1. 基于elasticsearch-5.6.0
  2. 机器配置: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"

优化参数详解

  1. 精细设置全文域:string类型字段默认会分词,不仅会额外占用资源,而且会影响创建索引的速度。所以,把不需要分词的字段设置为not_analyzed
  2. 禁用_all字段:对于日志和apm数据,目前没有场景会使用到
  3. 副本数量设置为0:因为我们目前日志数据和apm数据在es只保留最近7天的量,全量日志保存在hadoop,可以根据需要通过spark读回到es – 况且副本数量是可以随时修改的,区别分片数量
  4. 使用es自动生成id:es对于自动生成的id有优化,避免了版本查找。因为其生成的id是唯一的
  5. 设置index.refresh_interval:索引刷新间隔,默认为1s。因为不需要如此高的实时性,我们修改为30s – 扩展学习:刷新索引到底要做什么事情
  6. 设置段合并的线程数量:
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)

  1. 设置异步刷盘事务日志文件:
"index.translog.durability": "async",
"index.translog.sync_interval": "30s"

对于日志场景,能够接受部分数据丢失。同时有全量可靠日志存储在hadoop,丢失了也可以从hadoop恢复回来

  1. 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: 300
  1. 设置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)原则去学习。

Elasticsearch(ES)作为NOSQL+搜索引擎的有机结合体,不仅有近实时的查询能力,还具有强大的聚合分析能力。因此在全文检索、日志分析、监控系统、数据分析等领域ES均有广泛应用。而完整的Elastic Stack体系(Elasticsearch、Logstash、Kibana、Beats),更是提供了数据采集、清洗、存储、可视化的整套解决方案。 本文基于ES 5.6.4,从...
On Heap&&Off Heap Elasticsearch内存分为on heap以及off heap两部分。Elasticsearch能控制的是On Heap内存部分,这部分由JVM管理;Off Heap由Lucene管理,负责缓存倒排索引数据空间(Segment Memory)。 On Heap Indexing Buffer索引写入缓冲区,用于存储新写入的文档,当其被填满时,缓冲区中的文档被写入磁盘中的 segments 中。节点上所有 shard 共享。这部分空...
在ES的默认设置下,是综合考虑数据的可靠性,搜索实时性,写入速度等因素的。当离开默认设置,追求极致写入速度时,很多是以牺牲可靠性和搜索实时性为代价的。有时候,业务上对数据可靠性和搜索实时性要求不高,反而对写入速度要求很高,此时可以调整一些策略,最大化写入速度。 综合来说可以从以下几个方面入手: 加大translog flush间隔,目的是降低iops,writeblock (可靠性降低) 加大index refresh间隔,除了降低I/O,更重要的是降低segment merge频率 调整bulk
所有的修改都可以在elasticsearch.yml里面修改,也可以通过api来修改。推荐用api比较灵活 1.不同分片之间的数据同步是一个很大的花费,默认是1s同步,如果我们不要求实时性,我们可以执行如下: $ curl -XPUT 'http://localhost:9200/twitter/' -d '{ "settings" : { "index" : ...
1、用bulk批量写入 你如果要往es里面灌入数据的话,那么根据你的业务场景来,如果你的业务场景可以支持让你将一批数据聚合起来,一次性写入es,那么就尽量采用bulk的方式,每次批量写个几百条这样子。 bulk批量写入的性能比你一条一条写入大量的document的性能要好很多。但是如果要知道一个bulk请求最佳的大小,需要对单个es node的单个shard做压测。先bulk写入100个doc...
"number_of_shards": 5, "number_of_repl
我的es数据规模为5433万,这个时候频繁执行查询、写入的操作,发现python执行有一些异常,记录下来,看看有没有解决的办法 from elasticsearch import Elasticsearch from elasticsearch import helpers body = { "query": { "range": ...
GC类型:-XX:+UseG1Gc -XX:MaxGCPauseMillis=200 。 其他默认。 二、Es集群配置:cluster.name: estest node.name: “testanya”node.master: false node.data: trueindex.store.type 最权威的,当然就是官方文档,根据自己所安装的版本进行选择:elasticsearch所有版本参考文档 如果英文文档阅读有困难,参考:Elasticsearch: 权威指南,但是中文文档有滞后性,比如目前es已经到6.X版本,而中文文档以2.X版本为基础,因此对于新版本的话会有部分不适用。 参考博客:铭毅天下
每个Elasticsearch节点内部都维护着多个线程池,如index、search、get、bulk等,用户可以修改线程池的类型和大小,线程池默认大小跟CPU逻辑一致 一、查看当前线程组状态 curl -XGET 'http://localhost:9200/_nodes/stats?pretty' "thread_pool" : {
文章目录1 前言2 translog flush间隔调整2.1 index.translog.durability2.2 index.translog.flush_threshold_size3 索引刷新间隔refresh_interval4 段合并优化    在集群正常运行的前提下,如果是集群首次批量导入数据时,可以将副本数设置为0,导入完毕后再将副本数调整为正常值,这样副分片就只需...