Inside the JVM Heap
- Elasticsearch的缓存主要分成三大类
- Node Query Cache（Filter Context）
- Shard Query Cache（Cache Query的结果）
- Fielddata Cache
cache
Node Query Cache
- 每一个节点有一个Node Query 缓存
- 由该节点的所有Shard共享，只缓存Filter Context相关内容
- Index Level：index.queries.cache.enabled: true
Shard Request Cache
- 缓存每个分片上的查询结果
- 只会缓存设置size=0的查询对应的结果。不会缓存hits。但是会缓存Aggregations和Suggestions
- Cache Key
- LRU算法，将整个JSON查询串作为Key，与JSON对象的顺序相关
- 静态配置
- 数据节点：indices.requests.cache.size="1%"
PUT my_index
{
"settings": {
"index.request.cache.enable": false
}
}
GET my_index/_search?request_cache=true
{
"size": 0,
"aggs": {
"popular_colors": {
"terms": {
"field": "colors",
"size": 10
}
}
}
}
Fielddata Cache
- 除了Text类型，默认都采用doc_values。节约了内存
- Aggregation的Global ordinals也保存在Fielddata cache中
- Text类型的字段需要打开Fielddata才能对其进行聚合和排序
- Text经过分词，排序和聚合效果不佳，建议不要轻易使用
- 配置
- 可以控制indices.fielddata.cache.size，避免产生GC（默认无限制）
缓存失效
- Node Query Cache
- 保存的是Segment级缓存命中的结果。Segment被合并后，缓存会失效
- Shard Request Cache
- 分片Refresh时候，Shard Request Cache会失效。如果Shard对应的数据频繁发生变化，该缓存的效率会很差
- Fielddata Cache
- Segment被合并后，会失效
管理内存的重要性
- Elasticsearch高效运维依赖于内存的合理分配
- 可用内存一半分配给JVM，一半分配给操作系统，缓存索引文件
- 内存问题，引发的问题
- 长时间GC，影响节点，导致集群响应很慢
- OOM，导致丢节点
诊断内存状况
- 查看各个节点的内存状况
- GET _cat/nodes?v
- GET _nodes/stats/indices?pretty
- GET _cat/nodes?v&h=name.queryCacheMemory,queryCacheEvictions,requestCacheMemory,requestCacheHitCount,request_cache.miss_count
- GET _cat/nodes?h=name,port,segments,memory,segments.index_write_memory,fielddata.memory_size,query_cache.memory_size,request_cache.memory_size&v
一些常见的内存问题
Segments个数过多，导致full GC
- 现象：集群整体响应缓慢，也没有特别多的数据读写。但是发现节点在持续进行Full GC
- 分析：查看Elasticsearch的内存使用，发现segments.memory占用很大空间
- 解决：通过force merge，把segments合并成一个
- 建议：对于不再写入和更新的索引，可以将其设置成只读。同时，进行force_merge操作。如果问题依然存在，则需要考虑扩容。此外，对索引进行force_merge，还可以减少对global_oridinals数据结果的结构，减少对fielddata cache的开销
Field data cache过大，导致full GC
- 现象：集群整体响应缓存，也没有特别多的数据读写。但是发现节点在持续进行Full GC
- 分析：查看Elasticsearch的内存使用，发现fielddata.memory.size占用很大空间。同时，数据不存在写入和更新，也执行过segments.merge
- 解决：将indices.fielddata.cache.size设小，重启节点，堆内存恢复正常
- 建议：Field data cache的构建比较重，Elasticsearch不会主动释放，所以这个值应该设置的保守一些。如果业务上确实有所需要，可以通过增加节点，扩容解决。
复杂的嵌套查询，导致建full GC
- 现象：节点响应缓慢，持续进行full GC
- 分析：导出Dump分析，发现内存中有大量bucket对象，查看日志，发现复杂的嵌套聚合
- 解决：优化聚合
- 建议：在大量数据集上进行嵌套聚合查询，需要用到很大的堆内存来完成。如果业务场景确实需要。则需要增加硬件进行扩展。同时，为了避免这类查询影响整个集群，需要设置Circuit Break和search.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统计信息
- GET /_nodes/stats/breaker?
- Trippped大于0，说明有过熔断
- Limit size与estimated size约接近，越可能引发熔断
breaker stats
- 千万不要触发了熔断，就盲目调大参数，有可能会导致集群出问题，也不应该盲目调小，需要进行评估
- 建议将集群升级到7.x，更好的Circuit Breaker实现机制
- 增加了indices.breaker.total.use_real_memory配置，可以增加精准的分析内存状况，避免OOM
https://www.elastic.co/blog/improving-node-resiliency-with-the-real-memory-circuit-breaker
- 增加了indices.breaker.total.use_real_memory配置，可以增加精准的分析内存状况，避免OOM
