ES的缓存主要分成三大类

Node Query Cache (Filter Context）Shard Query Cache (Cache Query的结果）Fielddata Cache

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

Shard Request Cache

缓存每个分片上的查询结果

只缓存设置了size=0的查询对应的结果。不会缓存hits。但是会缓存聚合 和建议cache key: lru算法，将整个json串查询串作为key,与json对象的顺序相关静态配置：数据节点：indices.requests.cache.size: "1%"

Fielddata Cache

除了text类型，默认都采用doc-values。节约了内存：聚合的global ordinals 页保存在Fielddata cache中

text类型的字段需要打开Fileddata 才能对其进行聚合和排序：text经过分词，排序和聚合效果不佳，建议不要轻易使用

配置：可以控制indices.fielddata.cache.size避免产生GC （默认无限制）

缓存失效

Node Query Cache： 保存的是segment级缓存命中的结果。segment被合并后，缓存会失效

Shard Request Cache: 分片Refresh时候，shard request cache 会失效。如果shard对应的数据频繁发生变化，该缓存的效率会很差

Fielddata Cache: segment被合并后，会失效

管理内存的重要性

es高效运维依赖于内存的合理分配：可用内存的一半分配给jvm，一半留给操作系统，缓存索引文件

内存引发的问题：

长时间gc，影响节点，导致集群响应缓慢

oom导致丢节点

诊断内存状况

一些常见的内存问题

segments 个数过多，导致full gc

现象：集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行full gc

分析：查看es的内存使用，发现segments.memory占用很大空间

解决：通过force merge 把segments合并成一个

建议：对于不再写入和更新的索引，可以将其设置成只读。同时，进行force merge操作。如果问题依然存在，则需要扩容。此外对索引进行force merge还可以减少global_ordinal数据结构的构建，减少对fielddata cache的开销

fielddata cache过大，导致full gc

现象：集群整体响应缓慢，也没有特别多的数据读写。但是发现节点再持续进行full gc

分析：查看es的内存使用，发现fielddata.memory.size 占用很大空间。同时，数据不存在写入和更新，也执行过segments merge

解决：将indices.fielddata.cache.size 设小，重启节点，堆内存恢复正常

建议：fielddata cache的构建比较重，es不会主动释放，所以整个值应该设置的保守一些。如果业务上确实由需要，可以增加节点扩容。

复杂的嵌套聚合，导致集群full gc

现象：节点响应缓慢，持续进行full gc

分析：导出dump分析。发现内存中大量bucket对象，查看日志，发现复杂的嵌套聚合

解决：优化聚合

建议：在大量数据集上进行嵌套聚合查询，需要很大的堆内存来完成。如果业务场景确实需要。则需要增加硬件扩展。同时为了避免这类查询影响整个集群，需要设置circuit break 和 seach.max_buckets的数值

circuit breaker

包含多种断路器，避免不合理操作引发的oom，每个断路器可以指定内存使用限制

parent circuit breaker :设置所有的熔断器可以使用的内存总量fielddata circuit breaker : 加载fielddata所需要的内存request circuit breaker: 防止每个请求数据结构超过一定的内存（例如：聚合计算的内存)in flight circuit breaker: request中的断路器accounting request circuit breaker :请求结束后不能释放对象所占用的内存

circuit breaker统计信息