elasticsearch调优技巧

elasticsearch 性能调优

所有的修改都可以在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亿左右数据量，比较稳定

三、线程池类型

1、cached

无限制的线程池，为每个请求创建一个线程。这种线程池是为了防止请求被阻塞或者拒绝，其中的每个线程都有一个超时时间(keep_alive)，默认5分钟，一旦超时就会回收/终止。elasticsearch的generic线程池就是用该类型。最近发现5.0.0-alpha2版本中去掉了该类型的线程池。

[html]view
 plain copy

threadpool:  

    generic:  

        keep_alive: 2m  

2、fixed

有着固定大小的线程池，大小由size属性指定，默认是5*cores数，允许你指定一个队列（使用queue_size属性指定，默认是-1，即无限制）用来保存请求，直到有一个空闲的线程来执行请求。如果Elasticsearch无法把请求放到队列中（队列满了），该请求将被拒绝。

[html]view
 plain copy

threadpool:  

    index:  

        size: 30  

        queue_size: 1000  

3、scaling

可变大小的pool，大小根据负载在1到size间，同样keep_alive参数指定了闲置线程被回收的时间。

[html]view
 plain copy

threadpool:  

    warmer:  

        size: 8  

        keep_alive: 2m  

四、修改线程池配置

1、elasticsearch.yml

[html]view
 plain copy

threadpool.index.type: fixed  

threadpool.index.size: 100  

threadpool.index.queue_size: 500  

2、Rest API

[html]view
 plain copy

curl -XPUT 'localhost:9200/_cluster/settings' -d '{  

    "transient": {  

        "threadpool.index.type": "fixed",  

        "threadpool.index.size": 100,  

        "threadpool.index.queue_size": 500  

    }  

}'

五、bulk异常排查

使用es bulk api时报错如下

[html]view
 plain copy

EsRejectedExcutionException[rejected execution(queue capacity 50) on.......]  

这个错误明显是默认大小为50的队列（queue）处理不过来了，解决方法是增大bulk队列的长度

elasticsearch.yml

[html]view
 plain copy

threadpool.bulk.queue_size: 1000  

六、总结

Elasticsearch的线程池其实就是对java自带的进行封装，虽然用户可以更改相关配置，但官方强烈不建议去修改默认值，关于为什么，可以阅读下面第三篇文章。

Elasticsearch常用配置及性能参数

cluster.name: estest 集群名称
node.name: “testanya” 节点名称

node.master: false 是否主节点
node.data: true 是否存储数据

index.store.type: niofs 读写文件方式
index.cache.field.type: soft 缓存类型

bootstrap.mlockall: true 禁用swap

gateway.type: local 本地存储

gateway.recover_after_nodes: 3 3个数据节点开始恢复

gateway.recover_after_time: 5m 5分钟后开始恢复数据

gateway.expected_nodes: 4 4个es节点开始恢复

cluster.routing.allocation.node_initial_primaries_recoveries:8 并发恢复分片数
cluster.routing.allocation.node_concurrent_recoveries:2 同时recovery并发数

indices.recovery.max_bytes_per_sec: 250mb 数据在节点间传输最大带宽
indices.recovery.concurrent_streams: 8 同时读取数据文件流线程

discovery.zen.ping.multicast.enabled: false 禁用多播
discovery.zen.ping.unicast.hosts:[“192.168.169.11:9300”, “192.168.169.12:9300”]

discovery.zen.fd.ping_interval: 10s 节点间存活检测间隔
discovery.zen.fd.ping_timeout: 120s 存活超时时间
discovery.zen.fd.ping_retries: 6 存活超时重试次数

http.cors.enabled: true 使用监控

index.analysis.analyzer.ik.type:”ik” ik分词

thread pool setting

threadpool.index.type: fixed 写索引线程池类型
threadpool.index.size: 64 线程池大小（建议2~3倍cpu数）
threadpool.index.queue_size: 1000 队列大小

threadpool.search.size: 64 搜索线程池大小
threadpool.search.type: fixed 搜索线程池类型
threadpool.search.queue_size: 1000 队列大小

threadpool.get.type: fixed 取数据线程池类型
threadpool.get.size: 32 取数据线程池大小
threadpool.get.queue_size: 1000 队列大小

threadpool.bulk.type: fixed 批量请求线程池类型
threadpool.bulk.size: 32 批量请求线程池大小
threadpool.bulk.queue_size: 1000 队列大小

threadpool.flush.type: fixed 刷磁盘线程池类型
threadpool.flush.size: 32 刷磁盘线程池大小
threadpool.flush.queue_size: 1000 队列大小

indices.store.throttle.type: merge
indices.store.throttle.type: none 写磁盘类型
indices.store.throttle.max_bytes_per_sec:500mb 写磁盘最大带宽

index.merge.scheduler.max_thread_count: 8 索引merge最大线程数
index.translog.flush_threshold_size:600MB 刷新translog文件阀值