#作者：孙德新
文章目录
一、Elasticsearch缓存分类
1、Node Query Cache：
每一个节点有一个 Node Query 缓存
由该节点的所有 Shard 共享，只缓存 Filter Context 相关内容
Cache 采用 LRU 算法
静态配置，需要设置在每个 Data Node 上
Node Level - indices.queries.cache.size:”10%”
Index Level: index.queries.cache.enabled: true
2、Shard Request Cache：
缓存每个分片上的查询结果
只会缓存设置了 size=0 的查询对应的结果。不会缓存hits。但是会缓存 Aggregations 和 Suggestions
Cache Key
LRU 算法，将整个 JSON 查询串作为 Key，与 JSON对象的顺序相关
静态配置
数据节点: indices.requests.cache.size:“1%
3、Fielddata Cache：
除了 Text 类型，默认都采用 doc_values。:节约了内存。Aggregation 的 Global ordinals 也保存在 Fielddata cache 中
Text 类型的字段需要打开 Fileddata 才能对其进行聚合和排序。Text 经过分词，排序和聚合效果不佳，建议不要轻易使用
配置：可以控制 Indicesfielddatacachesize 避免产生 GC(默认无限制)
缓存失效：
Node Query,Cache。保存的是 Segment 级缓存命中的结果。Segment 被合并后，缓存会失效
Shard Request Cache：分片 Refresh 时候，Shard Request Cache 会失效。如果 Shard 对应的数据频繁发生变化，该缓存的效率会很差
Fielddata Cache：segment被合并后会失效
二、管理内存的重要性：
- Elasticsearch 高效运维依赖于内存的合理分配。可用内存一半分配给 JVM，一半留给操作系统，缓存索引文件
- 内存问题，引发的问题
长时间 GC，影响节点，导致集群响应缓慢
OOM.导致丢节点
三、内存常见的问题
案例一
问题：Segments 个数过多，导致 full GC
现象: 集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行 Full GC
分析: 查看 Elasticsearch 的内存使用，发现 segments.memory 占用很大空间
解决: 通过 force merge，把 segments 合并成一个
建议: 对于不在写入和更新的索引，可以将其设置成只读。同时，进行 force merge 操作。如果问题依然存在，则需要考虑扩容。此外，对索引进行 force merge ，还可以减少对global ordinals 数据结构的构建，减少对 fielddata cache 的开销
案例二
问题：Field data cache 过大，导致 full GC
现象: 集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行 Full GC
分析: 查看 Elasticsearch 的内存使用，发现 fielddata.memorysize 占用很大空间。同时，数据不存在写入和更新，也执行过 segments merge。
解决: 将indices.fielddata.cache.size 设小，重启节点，堆内存恢复正常
建议: Field data cache 的构建比较重，Elasticsearch 不会主动释放，所以这个值应该设置的保守一些。如果业务上确实有所需要，可以通过增加节点，扩容解决
案例三
问题：复杂的嵌套聚合，导致集群 full GC
现象: 节点响应缓慢，持续进行 Full GC
分析: 导出 Dump 分析。发现内存中有大量 bucket 对象，经过查看日志发现存在复杂的嵌套聚合
解决: 优化聚合
建议: 在大量数据集上进行嵌套聚合查询，需要很大的堆内存来完成。如果业务场景确实需要，则需要增加硬件进行扩展。同时，为了避免这类查询影响整个集群，需要设置 Circuit Break和 search.maxbuckets 的数值
案例四
包含多种断路器，避免不合理操作引发的 OOM，每个断路器可以指定内存使用的限制
Parent circuit breaker: 设置所有的熔断器可以使用的内存的总量
Fielddata circuit breaker: 加载 fielddata 所需要的内存
Request circuit breaker: 防止每个请求级数据结构超过一定的内存(例如聚合计算的内存)
In flight circuit breaker: Request中的断路器
Accounting request circuit breaker: 请求结束后不能释放的对象所占用的内存
Circuit Breaker 统计信息：
GETnodes/stats/breaker?
Tripped 大于 0，说明有过熔断。Limit size 与estimated size 约接近，越可能引发熔断。千万不要触发了熔断，就盲目调大参数，有可能会导致集群出问题，也不因该盲目调小，需要进行评估。建议将集群升级到 7.x，更好的Circuit Breaker实现机制。增加了indices.breaker.total.use real memory 配置项，可以更加精准的分析内存状况，避免 OOM
四、内参分配最佳实践
1、jvm heap分配
es默认会给jvm heap分配2个G的大小，对于几乎所有的生产环境来说，这个内存都太小了。如果用这个默认的heap size，那么生产环境的集群肯定表现不会太好。
有两个方式来调节es中的jvm heap size。设置环境变量ES_HEAP_SIZE。当es进程启动的时候，会读取这个环境变量的值，然后设置为jvm的heap size。举例，可以这样来设置：export ES_HEAP_SIZE=10g。此外，还可以在启动es进程的时候，传递一个jvm的option，比如：ES_JAVA_OPTS=“-Xms10g -Xmx10g” ./bin/elasticsearch，但是要注意-Xms和-Xmx最小和最大堆内存一定设置的一样，避免运行过程中的jvm heap resize，非常耗时。
在老版本的es中，比如es 2.x里面，一般推荐用ES_HEAP_SIZE环境变量的方式来设置jvm heap size。
在新版本的es中，比如es 5.x里面，一般推荐在jvm.options文件里面去设置jvm相关的参数。
2、将机器上少于一半的内存分配给es
一个常见的问题就是将es进程的jvm heap size设置的过于大了。比如有一台64G的机器，要给es jvm size设置64G内存，不不合理。有人认为，直接将机器上的可用的内存都分配给es jvm heap，性能是绝对高的，因为大量的数据都可以缓存在内存里面。
虽然heap对于es来说是非常重要的，jvm heap被es用来存放很多内存中的数据结构来提供更快的操作性能。但是还有另外一个内存的用户，那就是lucene。lucene的设计就是要使用底层的os filesystem cache来缓存数据结构。lucene的segment是保存在单独的文件中的。因为这些segment是不可变的，所以这些文件实际上也从来不会改变。这样的话，就可以更好的缓存这些文件，底层的os cache会将hot segment驻留在内存中以供更快的访问。这些segment包括了倒排索引（为了全文检索）以及正排索引（为了聚合操作）。lucene的性能是严重依赖于底层的os的，但是如果给了过多的内存到es的jvm heap，那么就没有足够的内存留给lucene。这会极大的影响性能。
es的性能很大的一块，其实是由有多少内存留给操作系统的os cache，供lucene去缓存索引文件，来决定的。所以说lucene的os cache有多少是非常重要的。
一般建议的是，将50%的内存分配给es jvm heap，然后留50%的内存给os cache。留给os cache的内存是不会不使用的，lucene会将剩下的内存全部用光，用来cache segment file。如果我们没有对任何分词的text field进行聚合操作，那么我们就不需要使用fielddata，甚至可以考虑给os cache更多的内存，因为fielddata是要用jvm heap。如果给jvm heap更少的内存，那么实际上es的性能反而会更好，因为更多的内存留给了lucene用os cache提升索引读写性能，同时es的jvm heap的gc耗时会更少。
3、不要给jvm分配超过32G内存
还有另外一个原因不要将过多的内存分配给es的jvm heap。如果heap小于32G的化，jvm会用一种技术来压缩对象的指针，object pointer。在java中，所有的对象都会被分配到heap中，然后被一个pointer给引用。object pointer会指向heap中的对象，引用的是二进制格式的地址。
对于32位的系统来说，jvm最大的heap size就是4G，解释一下，32位，0和1值，0和1在32位的组合是2^32次方的字节，除以1024就是多少k，再除以1024就是多少mb，再除以1024就是多少gb，最后算下来就是4G。对于64位的系统来说，heap size可以更大，但是64位的object pointer会耗费更多的空间，因为object pointer更大了。比浪费更多内存空间更恶劣的是，过大的object pointer会在cpu，main memory和LLC、L1等多级缓存间移动数据的时候，吃掉更多的带宽。
所以jvm用了一种技术，叫做compressed oops来解决object pointer耗费过大空间的问题。这个技术的核心思想是，不要让object pointer引用内存中的二进制地址，而是让object pointer引用object offset。这就意味着32位的pointer可以引用400万个对象，而不是400万字节。这也意味着，使用32位的pointer，最大的heap大小可以到32G。此时只要heap size在32G以内，jvm就会自动启用32位的object pointer，因为32位的对象指针，足够引用32G的内存了，就可以用32位的pointer替代64位的pointer。但是32位的pointer比64位的pointer可以耗费更少的内存耗费。
如果给jvm heap分配的内存小于32G，此时jvm会自动使用32位的object pointer，同时是让pointer指向对象的offset，32位的object pointer就足以引用32G的内存，同时32位的pointer占用的内存空间很少，对cpu和memory之间移动数据的带宽开销也很少。这个过程就叫做compressed oops。
但是一旦越过了32G这个界限，就是给jvm heap分配了超过32G的内存，就没有办法用32位的pointer+引用object offset的模式了，因为32位的pointer最多引用32G的内存，超过了32G，就没法用32位pointer。不用32位pointer，就只能用64位pointer，才能引用超过32G的内存空间。此时pointer就会退回到传统的object pointer引用对象的二进制地址的模式，此时object pinter的大小会急剧增长，更多的cpu到内存的带宽会被占据，更多的内存被耗费。实际上，不用compressed oops时，如果给jvm heap分配了一个40~50G的内存的可用空间，实际上被object pointer可能都要占据十几G的内存空间，可用的空间量，可能跟使用了compressed oops时的32GB内存的可用空间，20多个G，几乎是一样的。
因此即使有很多内存，但是还是要分配给heap在32GB以内，否则的话浪费更多的内存，降低cpu性能，而且会让jvm回收更大的heap。
综上所述，如果给jvm heap分配超过32G的内存，实际上是没有什么意义的，因为用64位的pointer，1/3的内存都给object pointer给占据了，这段内存空间就浪费掉了。还不如分配32G以内，启用compressed oops，可用空间跟你分配50个G的内存，是一样的。
所以也正是因为32G的限制，一般来说，如果es要处理的数据量上亿的话，几亿，或者十亿以内的规模，建议是用64G的内存的机器比较合适，有个5台可以。给jvm heap分配32G，留下32G给os cache。
4、在32G以内的话具体应该设置heap为多大？
这个是根据具体情况而定的，不是固定死的，根据不同的jvm和平台而变。一般而言，将jvm heap size设置为31G比较安全一些。主要是要确保说，你设置的这个jvm heap大小，可以让es启用compressed oops这种优化机制。此外，可以给jvm option加入-XX:+PrintFlagsFinal，然后可以打印出来UseCompressedOops是否为true。这就可以让我们找到最佳的内存设置。因为可以不断调节内存大小，然后观察是否启用compressed oops。
举例来说，如果在mac os上启动一个java 1.7，同时将heap size设置为32600mb，那么compressed oops是会开启的；但是如果设置为32766m，compressed oops就不会开启。相反的是，使用jdk 1.8的化，分配32766m，compressed oops是会开启的，设置为32767m，就不会开启。所以说这个东西不是固定的。根据不同的操作系统以及jvm版本而定。
在es启动日志中，我们可以查看compressed oops是否开启，比如下面的字样：[2015-12-16 13:53:33,417][INFO ][env] [Illyana Rasputin] heap size [989.8mb], compressed ordinary object pointers [true]。
5、对于有1TB内存的超大内存机器该如何分配？
如果机器是一台超级服务器，内存资源甚至达到了1TB，或者512G，128G，该怎么办？首先es官方是建议避免用这种超级服务器来部署es集群的，但是如果我们只有这种机器可以用的话，我们要考虑以下几点：
（1）我们是否在做大量的全文检索？考虑一下分配4~32G的内存给es进程，同时给lucene留下其余所有的内存用来做os filesystem cache。所有的剩余的内存都会用来cache segment file，而且可以提供非常高性能的搜索，几乎所有的数据都是可以在内存中缓存的，es集群的性能会非常高
（2）是否在做大量的排序或者聚合操作？聚合操作是不是针对数字、日期或者未分词的string？如果是的化，那么还是给es 4~32G的内存即可，其他的留给es filesystem cache，可以将聚合好用的正排索引，doc values放在os cache中
（3）如果在针对分词的string做大量的排序或聚合操作？如果是的化，那么就需要使用fielddata，这就得给jvm heap分配更大的内存空间。此时不建议运行一个节点在机器上，而是运行多个节点在一台机器上，那么如果我们的服务器有128G的内存，可以运行两个es节点，然后每个节点分配32G的内存，剩下64G留给os cache。如果在一台机器上运行多个es node，建议设置：cluster.routing.allocation.same_shard.host: true。这会避免在同一台物理机上分配一个primary shard和它的replica shard。
6、swapping
如果频繁的将es进程的内存swap到磁盘上，会对服务性能造成很大影响，内存中的操作都是要求快速完成的，如果需要将内存页的数据从磁盘swap回main memory的化，性能会有多差。如果内存被swap到了磁盘，那么100微秒的操作会瞬间变成10毫秒，那么如果是大量的这种内存操作呢？这会导致性能急剧下降。因此通常建议彻底关闭机器上的swap，swapoff -a，如果要永久性关闭，需要在/etc/fstab中配置
如果没法完全关闭swap，那么可以尝试调低swappiness至，这个值是控制os会如何将内存swap到磁盘的。这会在正常情况下阻止swap，但是在紧急情况下，还是会swap。一般用sysctl来设置，vm.swappiness = 1。如果swappiness也不能设置，那么就需要启用mlockall，这就可以让我们的jvm lock住自己的内存不被swap到磁盘上去，在elasticsearch.yml中可以设置：bootstrap.mlockall: true。