69 - ES缓存及使用Breaker限制内存使用

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
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成，浏览时请结合常识与多方信息审慎甄别。
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

相关阅读更多精彩内容

友情链接更多精彩内容