Elasticsearch--解决JVM 堆内存使用率很高的问题

亦凉 2024-03-27 09:00 56阅读 0赞

原文网址：[Elasticsearch--解决JVM 堆内存使用率很高的问题\_IT利刃出鞘的博客-CSDN博客][Elasticsearch--_JVM _IT_-CSDN]

## 简介 ##

**说明**

本文介绍如何解决ES的JVM 堆内存使用率很高的问题。

**官网网址**

[https://www.elastic.co/guide/en/elasticsearch/reference/current/size-your-shards.html][https_www.elastic.co_guide_en_elasticsearch_reference_current_size-your-shards.html]

[https://www.elastic.co/guide/en/elasticsearch/reference/current/fix-common-cluster-issues.html][https_www.elastic.co_guide_en_elasticsearch_reference_current_fix-common-cluster-issues.html]

## 问题描述 ##

高 JVM 内存使用率会降低集群性能并触发断路器错误（导致内存熔断）。

为了防止这种情况发生，如果节点的 JVM 内存使用率持续超过 **85%**，官方建议采取措施降低内存压力。

![0fa8508a9b3145c4a24b752913b53960.png][]

![5d2ad597680e4cdc8a9fd48a4e9e0f44.png][]

## 诊断 JVM 内存压力 ##

### 检查 JVM 内存使用情况 ###

借助：node stats API 进行排查

GET _nodes/stats?filter_path=nodes.*.jvm.mem.pools.old

结果

{
        "nodes": {
            "J2-fr3wzSqqJk9cwoi2urw": {
                "jvm": {
                    "mem": {
                        "pools": {
                            "old": {
                                "used_in_bytes": 179796016,
                                "max_in_bytes": 1798569984,
                                "peak_used_in_bytes": 179796016,
                                "peak_max_in_bytes": 1798569984
                            }
                        }
                    }
                }
            }
        }
    }

堆内存使用率为：used\_in\_bytes / max\_in\_bytes = 179796016/ 1798569984 = 9.99 6%，接近 10%。

能和 kibana 可视化监控结果保持一致：

![ab6f86e50f4a4cdfa0ba4ee5af7c90ec.png][]

### 垃圾回收日志检查 ###

随着内存使用量的增加，垃圾收集变得更加频繁并且需要更长的时间。

你可以在 elasticsearch.log 中跟踪垃圾收集事件的频率和时长。

例如，以下事件表明 Elasticsearch 在过去 40 秒中花费了超过 50%（21 秒）执行垃圾收集。

> \[timestamp\_short\_interval\_from\_last\]\[INFO \]\[o.e.m.j.JvmGcMonitorService\] \[node\_id\] \[gc\]\[number\] overhead, spent \[21s\] collecting in the last \[40s\]

## 降低JVM 堆内存使用率方案 ##

### 1. 减少分片数 ###

关于分片的几点认知：

**第一：搜索请求是以分片为单位发起的。**

至少 7.16 版本之前是，如下图示更能说明问题：

![3c8d12c571594e2ea49f6798cf8f725b.png][]

这暗示了什么？

必然是：分片越多，检索越慢。

因为：跨大量分片的搜索可能会耗尽节点的搜索线程池，这可能导致吞吐量低和搜索速度慢。

**第二：每个索引和分片都有内存和 CPU 开销。**

每个索引和每个分片都需要一些内存和 CPU 资源。

在大多数情况下，一小组大分片比许多小分片使用更少的资源。

![8b00788e50124cef947363def0085993.png][]

为什么呢？解释一下：

*  分片的底层是 Lucene 分段。
 *  段的元数据会保留在 JVM 堆内存中，以便快速检索。
 *  分片越多，意味着分段会越多，进而分段元数据会越多，JVM 堆内存使用率会越高。反之，则相反。

**第三：Elasticsearch 会在相同角色的节点间平衡分片。**

节点角色划分是 7.x 高版本新的节点定义方式，其目的是：节点用途更明确。

当添加新节点或某节点出故障时，Elasticsearch 会自动在相同角色层的剩余节点之间重新平衡索引的分片。

**关于减少分片数**，更确切的是如何合理规划分片，官方建议如下：

1.  尽量避免 delete\_by\_query 删除文档，更好的方案是直接删除索引。
2.  使用 datastrem 和 ILM 索引生命周期管理管理时序数据。
3.  分片大小控制在 10GB-50GB。
4.  控制在每 GB 堆内存 20 个分片以内。
    
    1.  也就是说：具有 30GB 堆内存的节点最多应该有 600 个分片。
5.  第五：避免单个节点分片过多、负载过重。
    
    1.  如果单个节点包含太多分片，且索引量很大，则该节点可能会出现问题。可以使用如下命令行加以控制：
        
            PUT my_index_001/_settings
            {
                "index":   {
                    "routing.allocation.total_shards_per_node":  5
                }
            }

### 2.避免复杂检索 ###

复杂搜索会占用大量的内存空间。建议启用：慢日志进行排查。

导致内存使用率飙升的复杂查询，通常具备如下的特点：

*  size 召回值设置的巨大；
 *  包含分桶值很大的聚合操作或者聚合嵌套很深；
 *  包含极其耗费资源的查询，举例：script 查询、fuzzy 查询、regexp 查询、prefix 查询、wildcard查询、text 或 keyword 上的 range 查询。

为避免复杂查询，常规措施如下：

1.  限制：index.max\_result\_window 的大小。
    
    1.      PUT _settings
            {
              "index.max_result_window": 5000
            }
2.  设置 search.max\_buckets cluster 以限制分桶值大小。
    
    1.      PUT _cluster/settings
            {
              "persistent": {
                "search.max_buckets": 20000,
              }
            }
3.  设置 search.allow\_expensive\_queries 直接禁用耗费资源的查询。
    
    1.      PUT _cluster/settings
            {
              "persistent": {
                "search.allow_expensive_queries": false
              }
            }

### 3.避免 Mapping “爆炸” ###

定义过多的字段或嵌套过深的字段会导致使用大量内存，出现“Mapping 爆炸" 现象。

为防止“Mapping 爆炸“，使用映射限制设置来限制字段映射的数量。

PUT my_index_001/_settings
    {
        "index.mapping.total_fields.limit": 100
    }

更多类似参数，见官网：[https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html][https_www.elastic.co_guide_en_elasticsearch_reference_current_mapping-settings-limit.html]

### 4.分散批量请求 ###

批量请求虽然比单个请求更有效，但大批量写入（以 bulk 操作为代表）或多搜索请求（以 \_msearch 为代表）仍然会产生较高的 JVM 内存压力。

如果可能，提交较小（小是个相对值，需要根据集群性能测算出适合自己集群的经验值）的请求并在它们之间留出更多时间时隔。

## 5.升级节点内存 ##

繁重的写入操作和搜索负载过重均会导致高 JVM 内存压力。

为了更好地处理繁重的工作负载，在其他方法都不灵的情况下，可以考虑通过为节点内存扩容以达到升级节点目的。

这是无法之法，这是万能之法。

[Elasticsearch--_JVM _IT_-CSDN]: https://knife.blog.csdn.net/article/details/128752672
[https_www.elastic.co_guide_en_elasticsearch_reference_current_size-your-shards.html]: https://www.elastic.co/guide/en/elasticsearch/reference/current/size-your-shards.html
[https_www.elastic.co_guide_en_elasticsearch_reference_current_fix-common-cluster-issues.html]: https://www.elastic.co/guide/en/elasticsearch/reference/current/fix-common-cluster-issues.html
[0fa8508a9b3145c4a24b752913b53960.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/19599890482c4ecb9b1206f43a4b7466.png
[5d2ad597680e4cdc8a9fd48a4e9e0f44.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/7be54cdded2e4d01ae278672cf48a0cc.png
[ab6f86e50f4a4cdfa0ba4ee5af7c90ec.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/b02f58599e5848278c15b8af5c8da1a9.png
[3c8d12c571594e2ea49f6798cf8f725b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/e575af36259f422496fcb921f58623b7.png
[8b00788e50124cef947363def0085993.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/27/78e12b00c0d144f4aacb64570490456a.png
[https_www.elastic.co_guide_en_elasticsearch_reference_current_mapping-settings-limit.html]: https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-settings-limit.html