优化Elasticsearch内存使用以实现最佳性能

Elasticsearch内存问题通常表现为搜索缓慢、垃圾回收暂停时间长、断路器错误或节点离开集群。优化Elasticsearch内存使用意味着平衡JVM堆、文件系统缓存、分片数量、查询行为和索引压力，而不仅仅是提高-Xmx。

目标很简单：为Elasticsearch提供足够的堆内存用于集群和查询工作，同时为操作系统留出足够的RAM来缓存Lucene段文件。

理解Elasticsearch内存组件

Elasticsearch在两大方面使用内存：

JVM堆： 存储集群元数据、索引缓冲区、查询结构、fielddata（如果启用）、缓存和其他Java对象。堆太小会导致压力和断路器触发。堆太大可能会延长垃圾回收时间并占用文件系统缓存。
文件系统缓存和本机内存： 操作系统在JVM堆外缓存Lucene索引文件。Elasticsearch还使用本机内存进行网络通信、线程栈和内存映射文件。

配置JVM堆大小

堆大小是需要检查的第一个设置。Elasticsearch根据安装方式使用jvm.options文件或特定于环境的JVM选项。

同时设置`Xms`和`Xmx`

将-Xms和-Xmx设置为相同的值，以便JVM在节点运行时不会调整堆大小。

根据经验法则，将堆保持在物理RAM的一半或以下，并避免超过压缩普通对象指针阈值。在实践中，许多生产节点的堆保持在约30 GB以下，但您应该根据您的Elasticsearch和JVM版本验证确切的阈值和指导。

例如：

-Xms4g
-Xmx4g

这将初始和最大堆都设置为4 GB。

监控堆使用情况

使用Kibana Stack Monitoring、Prometheus导出器或节点统计API：

curl -X GET "localhost:9200/_nodes/stats/jvm?pretty"

关注heap_used_percent、垃圾回收时间、老年代压力和断路器触发次数。如果垃圾回收后堆长时间保持高位，通常意味着您需要减少堆消耗者或增加容量。

减少分片和查询内存压力

索引布局和查询形状直接影响内存。

分片大小和数量

每个分片都有开销。太多的小分片会浪费堆内存并减慢集群操作。非常大的分片可能会使恢复和重新分配变得困难。许多集群在分片大小为几十GB时运行良好，但日志、时间序列数据和搜索密集型索引可能需要不同的目标。

例如，如果每日日志索引为20 GB数据创建了30个主分片，那么您将为许多小分片支付开销。根据保留和查询模式，一个或两个主分片可能更易于管理。

段合并

Elasticsearch使用Lucene段进行索引。较小的段会随着时间的推移合并成较大的段。这个过程可能会消耗大量内存。虽然Elasticsearch会自动处理合并，但了解其影响仍然有益，尤其是在索引负载较重时。

搜索和聚合优化

对聚合使用keyword字段： 在keyword、数值、日期或其他支持doc-values的字段上进行聚合和排序。避免在大型text字段上启用fielddata，除非您了解其堆内存成本。
限制昂贵的查询： 前导通配符和宽泛的正则表达式查询可能代价高昂。当用例需要部分匹配时，优先使用结构化字段、前缀、n-gram或search-as-you-type映射。
分析慢速搜索： 在测试环境中使用profile API来查找产生最多工作的查询子句。

有意识地使用缓存

Elasticsearch有多个缓存。它们有助于重复工作，但也会消耗内存。

分片请求缓存： 缓存符合条件的请求的分片级搜索结果，通常对大多不变的数据上的重复聚合类查询有用。其大小通过以下方式控制：
```
indices.requests.cache.size: 5%
```
此示例将分片请求缓存大小设置为堆的5%。
节点查询缓存： 缓存过滤上下文的结果。其大小单独控制：
```
indices.queries.cache.size: 10%
```
Fielddata缓存： 消耗堆内存，如果在text字段上启用fielddata，可能会快速增长。优先正确映射字段，而不是依赖更大的fielddata缓存。

防止内存溢出错误

内存溢出错误通常是持续压力的最终结果。解决方法很少是“提高所有限制”。

将垃圾回收视为症状

最近的Elasticsearch版本为您选择了支持的JVM默认值。除非您有特定版本的指导和测量，否则避免自定义垃圾回收器调优。长时间的暂停通常指向过度分片、昂贵的聚合、fielddata、过多的堆压力或节点不足。

GC问题的关键指标包括：

高GC时间。
长时间的stop-the-world暂停。
每次回收后堆使用率再次接近限制。
在大型搜索、批量索引或聚合期间出现OOM错误。

尊重断路器

断路器估计内存使用并在操作耗尽节点之前拒绝它们。

Fielddata断路器： 限制用于fielddata的堆内存。
请求断路器： 限制用于完成请求数据结构的堆内存。
父断路器： 跟踪组合的断路器估计值。

查看断路器统计信息：

curl -X GET "localhost:9200/_nodes/stats/breaker?pretty"

您可以通过集群设置更改某些断路器设置，但只有在您知道断路器触发原因后才这样做。触发的断路器通常是在保护节点免受OOM影响。

监控和告警

对以下内容进行告警：

垃圾回收后的JVM堆使用率。
垃圾回收时间和长时间暂停。
断路器触发。
索引压力和拒绝的线程池任务。
操作系统内存压力和交换使用率。
每个节点的分片数量和异常大的聚合。

要点

从堆大小调整开始，然后检查分片数量、字段映射、大型聚合和重复的断路器触发。如果清理后节点仍然处于压力之下，请增加容量或拆分工作负载，而不是通过更大的限制来隐藏警告信号。