• 欢迎访问蜷缩的蜗牛博客 蜷缩的蜗牛
  • 微信搜索: 蜷缩的蜗牛 | 联系站长 kbsonlong@qq.com
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

elasticsearch 性能调优

ELK 蜷缩的蜗牛 6个月前 (05-04) 93次浏览 已收录
所有的修改都可以在 elasticsearch.yml 里面修改,也可以通过 api 来修改。推荐用 api 比较灵活
1.不同分片之间的数据同步是一个很大的花费,默认是 1s 同步,如果我们不要求实时性,我们可以执行如下:
$ curl -XPUT 'http://localhost:9200/twitter/' -d '{
    "settings" : {
        "index" : {
         "refresh_interval":"60s"
        }
    }
}'

 此处我们是修改为 60s 其实可以改为-1s  这样就是不刷新,我们需要在查询的时候进行一次索引刷新然后再查询,这个嘛就得看你们用户能容忍多少时间长度了。

2.选择正确的存储
       一般来说,如果运行的是64位操作系统,你应该选择 mmapfs。如果没有运行64位操作系统,为 UNIX 系统选择 niofs,为 Windows 系统选择 simplefs。如果你可以容忍一个易失的存储,但希望它非常快,可以看看memory存储,它会给你最好的索引访问性能,但需要足够的内存来处理所有索引文件、索引和查询。
3.优化 es 的线程池 
cache:这是无限制的线程池,为每个传入的请求创建一个线程。
fixed:这是一个有着固定大小的线程池,大小由 size 属性指定,允许你指定一个队列(使用 queue_size 属性指定)用来保存请求,直到有一个空闲的线程来执行请求。如果 Elasticsearch 无法把请求放到队列中(队列满了),该请求将被拒绝。有很多线程池(可以使用 type 属性指定要配置的线程类型),然而,对于性能来说,最重要的是下面几个。
index:此线程池用于索引和删除操作。它的类型默认为 fixed,size 默认为可用处理器的数量,队列的 size 默认为 300。
search:此线程池用于搜索和计数请求。它的类型默认为 fixed,size 默认为可用处理器的数量乘以 3,队列的 size 默认为 1000。
suggest:此线程池用于建议器请求。它的类型默认为 fixed,size 默认为可用处理器的数量,队列的 size 默认为 1000。
get:此线程池用于实时的 GET 请求。它的类型默认为 fixed,size 默认为可用处理器的数量,队列的 size 默认为 1000。
bulk:你可以猜到,此线程池用于批量操作。它的类型默认为 fixed,size 默认为可用处理器的数量,队列的 size 默认为 50。
percolate:此线程池用于预匹配器操作。它的类型默认为 fixed,size 默认为可用处理器的数量,队列的 size 默认为 1000。
elasticsearch.yml 中可以设置 :
threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue_size: 500
当然可以 restAPI 设置
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
    "transient": {
        "threadpool.index.type": "fixed",
        "threadpool.index.size": 100,
        "threadpool.index.queue_size": 500
    }
}'

 

4.index 过于庞大导致 es 经常奔溃

    es 最近老是挂掉,无缘无故,表现症状为 对于大小超过 100g 的 index(5 个分片 1e 数据量左右)插入超级慢,由于机器资源有限 ,只能想出 将每一天的数据建立一个 index+“yyyy-MM-dd” 这样可以有效缓解我们集群的压力,有人会说如果改成这种方案那么之前写的查询岂不是废了,其实很 easy,es 支持 index 通配符 比如你之前是 logment  现在是 logment2015-05-01 和 logment2015-05-02  现在只需要将查询的代码中 index 改为 logment* 就 ok 了 ,而且此法便于删除过期的 index 写一个定时任务就 ok 了 
    我们日志的架构是这样的 logstash(client1) 采集日志到 redis  然后通过 logstash(client2) 从 redis 转至 elasticsearch ,logstash 写入 elasticsearch 的时候默认就是按照每天来建立索引的 在其配置文件无需指明 index 和 type 即可。 

    此处会产生一个问题,就是 logstash 自动建立索引的时候是根据格林尼治时间来建立的 正正比我们的时间 迟了 8 小时,我们需要在 logstash 的 lib 里面找到 event.rb  然后找到 org.joda.time.DateTimeZone.UTC 格林尼治时间  改成 org.joda.time.DateTimeZone.getDefault() (获取本地时间类型 我这边运行就是中国/上海) 即可  话说 logstash 用的居然是大名鼎鼎的 joda 果然是优秀程序 。

5. 采用 G1 垃圾回收机制代替默认 CMS

    这里我不分析 cms 和 g1 的细节区别,大内存(超过 8g)下 G1 还是很给力的,亲测有效,用了 G1 一周内一次 FULLGC 都没有,哈哈

    elasticsearch.in.sh 内 将

# Force the JVM to use IPv4 stack
if [ "x$ES_USE_IPV4" != "x" ]; then
  JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
fi

JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"

JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"

  替换为

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"

  大功告成

      顺便说句 JVM 调优,调优最主要目标:1.就是降低 GC 次数时间;2.降低 FULLGC 几率

      PS:优化代码比优化 JVM 实在多了

6. 清理掉没用的缓存

   回忆之前的问题发现 jvm 调优对于老年代的回收并没有很显著的效果,随着时间的推移内存还是不够~后来才发现是 es cache 的问题

 其实集群建立时我们是可以调整每隔节点的缓存比例、类型、者大小的

   

# 锁定内存,不让 JVM 写入 swapping,避免降低 ES 的性能
bootstrap.mlockall: true
# 缓存类型设置为 Soft Reference,只有当内存不够时才会进行回收
index.cache.field.max_size: 50000
index.cache.field.expire: 10m
index.cache.field.type: soft

   但是如果你不想重新配置节点并且重启,你可以做一个定时任务来定时清除 cache 

http://10.22.2.201:9200/*/_cache/clear  //清除所有索引的 cache,如果对查询有实时性要求,慎用!

   到了晚上资源空闲的时候我们还能合并优化一下索引

http://10.22.2.201:9200/*/_optimize

  

   截止现在我们 es 集群有 38 亿左右数据量,比较稳定~ 

 

      

 

本文转载自 elasticsearch 性能调优


蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明elasticsearch 性能调优
喜欢 (0)
[]
分享 (0)