Elasticesearch内存详解——3.内存优化

作为一个Java应用程序，Elasticsearch需要从系统的物理内存中分配一些逻辑内存(堆)。这应该最多是物理RAM的一半，上限为32GB。设置较高的堆使用率通常是为了应对开销较大的查询和更大的数据存储。父级熔断器默认值为95%，但我们建议在持续达到85%时就扩展资源。

2.1 elasticsearch配置文件

直接在本地 Elasticsearch 文件的 config > jvm.options 文件中配置。

## JVM configuration 
################################################################ 
## IMPORTANT: JVM heap size 
################################################################ 
… 
# Xms represents the initial size of total heap space 
# Xmx represents the maximum size of total heap space 
-Xms4g
-Xmx4g

2.2 docker-compose配置文件

作为 docker-compose 中的 Elasticsearch 环境变量。

version: '2.2'
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.12.0
    environment:
      - node.name=es01
      - cluster.name=es
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - discovery.type=single-node
    ulimits:
      memlock:
        soft: -1
        hard: -1
    ports:
      - 9200:9200

Elasticsearch 有一系列的断路器，它们都能保证内存不会超出限制：

• indices.breaker.fielddata.limit fielddata 断路器默认设置堆的 60% 作为 fielddata 大小的上限。
• indices.breaker.request.limit request 断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存的 60%。它实际上是node level的一个统计值，统计的是这个结点上，各类查询聚合操作，需要申请的Bigarray的空间大小总和。 所以如果有一个聚合需要很大的空间，同时在执行的聚合可能也会被break掉。
• indices.breaker.total.limit 父熔断，inflight、request(agg)和fielddata不会使用超过堆内存的 70%。
• network.breaker.inflight requests.limit 限制当前通过HTTP等进来的请求使用内存不能超过Node内存的指定值。这个内存主要是限制请求内容的长度。 默认100%。
• script.max_compilations_per_minute
• 限制script并发执行数，默认值为15。

数据索引存储在sub-shards中，sub-shards利用堆进行维护，并搜索/写入请求。shard大小上限应为50GB，数量上限由以下的公式确定:

shards <= sum(nodes.max_heap) * 20

在上述的Elasticsearch Service示例中，两个区域之间有8GB的物理内存 （总共分配两个节点）。

# node.max_heap 
8GB of physical memory / 2 = 4GB of heap  
# sum(nodes.max_heap) 
4GB of heap * 2 nodes = 8GB 
# max shards 
8GB * 20 
160

然后将其与_cat/allocation进行交叉比较

GET /_cat/allocation?v=true&h=shards,node
shards node
    41 instance-0000000001
    41 instance-0000000000

或与cluster/health进行交叉比较

GET /_cluster/health?filter_path=status,*_shards
{
  "status": "green",
  "unassigned_shards": 0,
  "initializing_shards": 0,
  "active_primary_shards": 41,
  "relocating_shards": 0,
  "active_shards": 82,
  "delayed_unassigned_shards": 0
}

所以这个部署有82个分片， 最大推荐值为160。 如果计数高于建议值，您可能会在接下来的两部分中遇到如下情况（见下文）。

如果任何分片在active_shards或active_primary_shards之外的报告>0，则表明您已经找到了引发性能问题的主要配置原因。

最常见的情况是，如果报告了一个问题，则unassignd_shards >0。如果这些 shard 是主要分片，您的集群将报告“状态：红色”，如果只是副本，则报告为“状态：黄色”。(所以在索引上设置副本很重要，这样，在集群遇到问题时可以恢复，不会丢失数据。)

假设我们有一个“状态：黄色”和一个未指派的shard。为了进行调查，我们将利用_cat/shards来查看是哪个索引分片出现了问题。

GET _cat/shards?v=true&s=state
index                                     shard prirep state        docs   store ip           node
logs                                      0     p      STARTED         2  10.1kb 10.42.255.40 instance-0000000001
logs                                      0     r      UNASSIGNED
kibana_sample_data_logs                   0     p      STARTED     14074  10.6mb 10.42.255.40 instance-0000000001
.kibana_1                                 0     p      STARTED      2261   3.8mb 10.42.255.40 instance-0000000001

这将用于我们的非系统索引日志，它有一个未指派的副本分片。让我们运行 _cluster/allocation/explain来看看问题出在哪儿（专业提示：当您升级到支持时，这正是我们所做的事情）。

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*
{ "index": "logs",
  "node_allocation_decisions": [{
      "node_name": "instance-0000000005",
      "deciders": [{
          "decider": "data_tier",
          "decision": "NO",
          "explanation": "node does not match any index setting [index.routing.allocation.include._tier] tier filters [data_hot]"
}]}]}

此错误消息指向data_hot，它是索引生命周期管理（ ILM）策略的一部分，说明我们的ILM策略与当前的索引设置不一致。在本例中，此错误的原因是在没有指定hot-warm的情况下设置了hot-warm ILM策略。(我必须让一些东西出错，因为这是我在给你们演示错误示例。看看你们对我做了什么 😂)。

仅供参考，如果没有unsigned shards情况下就运行此命令，将会出现一个400 错误：当前已没有未指派到节点的分片，因为没有任何错误报告。

如果您遇到非逻辑原因（例如，在分配期间节点离开集群之类的临时网络错误），您可以随时使用Elastic的 _cluster/reroute。

POST /_cluster/reroute

这一无需定制的请求将启动一个异步后台进程，尝试分配所有当前状态：NASSIGNED shards。（别像我一样等到它完成后才联系开发人员，我当时以为这是瞬间的，而且可以很巧地为他们及时完成升级，然后告诉他们一切正常，因为什么都没有了。)

最大化堆分配可能会引起对集群的请求超时或错误，而且，您的集群还会经常遇到熔断器异常这一问题。熔断会导致elasticsearch.log事件，例如：

Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [num/numGB], which is larger than the limit of [num/numGB], usages [request=0/0b, fielddata=num/numKB, in_flight_requests=num/numGB, accounting=num/numGB]

要进行调查，请查看您的heap.percent，方法是查看 _cat/nodes。

GET /_cat/nodes?v=true&h=name,node*,heap*
# heap = JVM (logical memory reserved for heap)
# ram  = physical memory
name                                node.role heap.current heap.percent heap.max
tiebreaker-0000000002 mv             119.8mb           23    508mb
instance-0000000001   himrst           1.8gb           48    3.9gb
instance-0000000000   himrst           2.8gb           73    3.9gb

或者，如果您之前已启用过它，请导航到 Kibana > Stack Monitoring。

如果您确定遇到了内存熔断问题，您应考虑暂时增加堆容量，以便给自己喘息的空间，并进行调查。在调查根本原因时，请查看您的集群代理日志或elasticsearch.log, 以此查找之前发生的连续事件。您需要查找：

● 高桶聚合

我发现，搜索在根据搜索大小或存储桶尺寸运行查询之前，临时分配了堆的某个端口，我觉得这太傻了，就设置 了10,000,000。我的运维团队为此很挠头。

● 非优化映射

感到愚蠢的第二个原因是，我认为搜索时如果利用分层报告会比扁平化数据更好（事实并非如此）。

● 请求量/速度：通常是批处理或异步查询

如果您已不止一次启动熔断机制，或者您觉得这个问题将一直存在（例如，始终达到85%，则应该考虑扩展资源了），您就需要仔细查看JVM内存压力，将其作为您的长期堆指标。 您可以在Elasticsearch Service > Deployment中进行检查。

或者您可以根据 _nodes/stats进行计算

GET /_nodes/stats?filter_path=nodes.*.jvm.mem.pools.old
{"nodes": { "node_id": { "jvm": { "mem": { "pools": { "old": {
  "max_in_bytes": 532676608,
  "peak_max_in_bytes": 532676608,
  "peak_used_in_bytes": 104465408,
  "used_in_bytes": 104465408
}}}}}}}

这里

JVM Memory Pressure = used_in_bytes / max_in_bytes

可能会出现的是情况是：elasticsearch.log中的垃圾收集器(gc)事件发生的频率很高，而且持续时间长

[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s]

如果您确认了这一情况，那么您需要考虑一下如何扩展您的集群，或者如何减少对集群的需求。你应该调查并考虑的方面包括:

● 增加堆资源（堆/节点、节点数量）

● 减少shards（删除不必要的或旧的数据，利用ILM将数据放入热/冷存储中，之后您就可以缩减数据，关闭那些即使丢失了您也不在乎的数据副本)