4.3.3.Elasticsearch 性能优化之内存和熔断浅析
创作人：齐乐
审稿人：周海清
在 Elasticsearch 生产环境中，性能问题一直是各厂商最头疼的问题，而其中的痛点就是内存
相关。Elasticsearch 作为当前搜索引擎市场的 No.1，其显著特点就是检索速度非常快。之所以
Elasticsearch 检索速度快，离不开其底层的合理存储结构以及对内存的充分利用，其中包括大
量的缓存。由于 Elasticsearch 和其底层依赖的 Lucene 均为内存的使用大户，在生产环境中
经常会遇到一些内存相关的问题以及想要优化的欲望，本文主要浅析 Elasticsearch 内存使用
情况和其自带的内存保险——熔断机制。
首先我们会分析一些生产环境中遇到的内存相关问题；然后我们会从 JVM 层面以及 Elasticse
-arch 层面分别介绍内存相关的配置和使用；最后我们会学习 Elasticsearch 的内存熔断机制。
1. 生产中遇到的内存相关问题
你是否也经常在 Elasticsearch 的生产环境中遇到一下问题？
·Elasticsearch 内存占用过高且持续不会缓解
·节点频繁 GC 且耗时较长
· 查询响应时间过长甚至直接失败
· 修改相关功能或性能配置直接导致集群出现 OOM 等异常情况
· ......
希望本篇文章能给你带来一些启发或者问题的解决方案。
2. JVM 相关配置
本章主要对 Elasticsearch 的 JVM 配置进行基本介绍：由于 Elasticsearch 运行于 JVM 容器
之中，合理的配置 JVM 参数可以达到更好的内存使用效果，以下从内存大小和垃圾回收两个方
面分析：
本章主要对 Elasticsearch 的 JVM 配置进行基本介绍：由于 Elasticsearch 运行于 JVM 容器
之中，合理的配置 JVM 参数可以达到更好的内存使用效果，以下从内存大小和垃圾回收两个方
面分析：
·内存大小
Xms 和 Xmx 设置为相同的值，且不要超过系统内存的 50%。一般建议配置在 JVM 指针
压缩技术最大值范围之内，可以通过日志中的 compressed ordinary object pointers [tru
e] 来判断是否开启了指针压缩；如果有特殊需求(例如查询需要占用大量内存的情况)，可以
将内存调大，但是需要配置 40GB 乃至 50GB 以上的内存才能追平指针压缩技术带来的性
能优化，基本不建议这样使用(对 CPU 和 GC 等都有性能损耗)。
·垃圾回收器
使用 G1 相比 CMS 更适合大内存使用场景，一般默认参数即可：
G1ReservePercent：老年代预留给新生代对象晋升的分配担保比例。如果新生代经常晋升
失败而导致 Full GC，可以适当调高此阈值，意味着降低了老年代的实际可用空间，使用
Elasticsearch 默认配置即可。
InitiatingHeapOccupancyPercent：触发老年代全局并发标记的比例，使用 Elasticsearc-
h 默认配置即可。
MaxGCPauseMillis：GC 最大的停顿毫秒数。如果业务对 GC 比较敏感，可以适当调小，但
是会增加 CPU 的开销，建议 50-200 之间。
3. ES 内存的使用
本章主要浅析 Elasticsearch 将内存使用到了哪里，可以参考图 1 和图 2 ：Elasticsearch 使
用的内存分为堆内存和堆外内存；同时堆内内存又分为可以 GC 和不可以 GC，不可 GC 的部
分采用 LRU 方式进行缓存更新。
图 1 Elasticsearch 内存分布
图 2 Elasticsearch 堆内存分布
接下来具体分析每个占用内存的部分：
·indices.queries.cache.size
默认 10%，node 级别，用于缓存 filter 查询。
·indices.fielddata.cache.size
默认无界，正排索引缓存及全局序数，用于聚合排序等操作。
·index.requests.cache.size
默认 1%，shard 级别，查询请求缓存，不缓存 hits，只缓存聚合结果。
·Segment Memory
倒排索引相关内容，且与上述三个缓存不同，调用 POST /_cache/clear 不能清除。处理这
部分内存的方式有以下几种：
○ 提前规划好 Mapping：不需要存储的内存不存储(评分，词距，词频和偏移等)。
○ Force Merge：可以清理 Deleted 的文档，将大量较小的 Segment 和并可以占用更少的
内存且加快查询。
○ 关闭或者删除不需要使用的索引，也可采用快照和可搜索快照方式处理。
另外 ES 7.X（ Lucene 8.X ）以后将 FST 从堆内存移到了堆外内存，大大减少了 Segm-
ent Memory 对内存的占用（线上测试一个 5GB 的 Segment 占用内存减少了 400 多倍）。
具体实现方案是将 FST 从堆内存中剔除， 直接交由 MMAP 管理，即通过 MMAP 读取倒
排索引的索引文件.tip。
indices.memory.index_buffer_size
默认 10%， bulk 写请求的缓存优化配置。
indexing_pressure.memory.limit
默认 10%，用于处理数据索引压力，即数据写入过程中的路由和主副同步工作。
使用中耗费的内存
非业务高峰期情况下保证集群堆内存负载在 70% 以下较为健康，超过这个值代表数据量过
多。除此以外，业务高峰期集群会耗费大量内存，主要是聚合等查询请求占用，前期设置可
以有效避免集群这部分压力过大，包括 Mapping 优化、预计算（使用 Ingest Pipeline）等
多种方式减小集群查询的压力。
·脚本相关及其他未知部分
脚本(正则)、pipeline 和 scroll 等均会占用部分内存。
了解了 Elasticsearch 内存方面的使用，我们还需要在日常维护集群时监控它们，对此 Elastic
-search 提供了丰富的 API：
·GET _cat/nodes?h=name,*heap*,*memory*,*Cache*&format=json 可以监控到节点的部
分内存使用情况和缓存命中情况。
·GET _cat/indices/test1?h=*memory*&format=json 可以监控某个索引部分内存占用情况。
·GET _cat/indices/?s=segmentsMemory:desc&v&h=index,segmentsCount,segmentsMem
ory,memoryTotal,mergesCurrent,mergesCurrentDocs,storeSize 可以查看集群内每个索引
Segment 的整体情况和合并情况。
·GET _cat/segments/test1?v 可以查看索引内每个段占用内存情况。
·GET _nodes/stats/indexing_pressure?human7.X 版本可以查看 indexing pressure 情
况。
建议对 Elasticsearch 提供的监控类 API 进行较为熟练的运用，包括但不限于：使用 ?help 进
行 API 的学习、查看配置信息时使用 include_defaults 展示默认配置及使用 flat_settings 展铺
平配置、使用 human 可视化以及 bytes 返回结果单位设置等。
《Elastic Stack 实战手册》——四、应用实践——4.3 性能优化场景——4.3.3.Elasticsearch 性能优化之内存和熔断浅析（中）: https://developer.aliyun.com/article/1225156?spm=a2c6h.13148508.setting.19.438f4f0e18NXNE
