适用于解决 Elasticsearch 内存分配问题的技巧和资源。

大家好啊！随着 Elastic 扩展我们的 Elasticsearch Service Cloud 产品和自动上线流程，我们已经将 Elastic Stack 的受众范围从运营团队全员扩展到了数据工程师、安全团队和顾问。作为一名 Elastic 支持工程师，我很喜欢与更多具有不同背景、用例甚至更广的用户进行互动。&nbsp;
随着服务对象的增多，我接触到了更多关于管理资源分配方面的问题，特别是晦涩难懂的分片堆比和避免触发熔断器的问题，不免让人无从理解。我也是心有戚戚焉！在开始使用 Elastic Stack 时，我也遇到了同样的问题。这是我第一次介绍如何管理 Java 堆和时序数据库分片，以及如何扩展自己的基础架构。
当我加入 Elastic 团队时，我除了喜欢阅读文档之外，还喜欢看我们的博客和教程，以便让我自己很快上手。但我入职的第一个月过得并不轻松，因为我要将理论知识与用户通过工单接连发送给我的各种错误联系起来。最后，和其他支持工程师一样，我发现所报告的错误中有不少都属于分配问题的症状，通过相同的七个链接便可让用户快速提升成功管理资源分配的能力。
在以下部分中，我将以支持工程师的身份，介绍我们发送给用户的主要分配管理理论链接、我们看到的主要症状，以及我们指引用户去哪里更新自己的配置来解决资源分配问题。
<h2>理论</h2>
作为一款使用 Java 开发的应用程序，Elasticsearch 需要从系统的物理内存中分配部分逻辑内存（堆）。这部分内存最大不超过物理 RAM 的一半，<a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops" target="_self">上限为 32GB</a>。设置较高的堆利用率通常是为了<a href="https://www.elastic.co/guide/en/cloud/current/ec-memory-pressure.html#ec-memory-pressure-causes" target="_self">应对</a>耗费资源的查询和较大的数据存储。<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/circuit-breaker.html#parent-circuit-breaker" target="_self">父级熔断器</a>默认在堆利用率为 95% 时触发，但我们建议在堆利用率<a href="https://www.elastic.co/cn/blog/found-understanding-memory-pressure-indicator#conclusion" target="_self">持续达到 85%</a> 时，就应该扩展一下资源了。&nbsp;
我强烈建议阅读以下由我们团队撰写的概述性文章，以了解更多信息：
<ul>
 <li aria-level="1"><a href="https://www.elastic.co/cn/blog/a-heap-of-trouble" target="_self">一“堆”麻烦</a></li>
 <li aria-level="1"><a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html" target="_self">堆：大小调整和交换</a></li>
 <li aria-level="1"><a href="https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster" target="_self">我在 Elasticsearch 集群内应该设置多少个分片？</a></li>
</ul>
<h2>配置</h2>
Elasticsearch 开箱即用的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.11/important-settings.html#heap-size-settings" target="_self">默认设置</a>会根据节点角色和内存总量自动调整 JVM 堆的大小。但是，您也可以根据需要通过以下三种方式直接进行配置：
1. 直接在本地 Elasticsearch 文件的 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.11/advanced-configuration.html#setting-jvm-heap-size" target="_self">config &gt; jvm.options</a> 文件中<pre class="prettyprint">## JVM 配置 ################################################################ ## 重要说明：JVM 堆大小 ################################################################ … #Xms 表示总堆空间的初始大小 #Xmx 表示总堆空间的最大大小 -Xms4g -Xmx4g </pre>
2. 作为 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.12/docker.html#docker-cli-run-prod-mode" target="_self">docker-compose</a> 中的 Elasticsearch 环境变量<pre class="prettyprint">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 </pre>
3. 通过我们的 Elasticsearch Service &gt;“Deployment”（部署）&gt;<a href="https://www.elastic.co/guide/en/cloud/current/ec-customize-deployment-components.html#ec-cluster-size" target="_self">“Edit”（编辑）视图</a>。注意：滑动条分配的是物理内存，约有一半会分配给堆。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt85a09eec61be50dc/60832291b775555b377675af/blog-elasticsearch-memory.png" data-sys-asset-uid="blt85a09eec61be50dc" alt="blog-elasticsearch-memory.png" />
<h2>故障排查</h2>
如果您的集群当前遇到性能问题，则很可能是以下常见问题所致
<ul>
 <li aria-level="1">配置问题：过度分片，无 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html" target="_self">ILM</a> 策略</li>
 <li aria-level="1">引入的高数据量：高请求速度/负载，叠加耗费资源的查询/写入</li>
</ul>
所有以下 cURL/API 请求都可以在 Elasticsearch Service &gt;“API Console”（API 控制台）中作为 Elasticsearch API 的 cURL 发出，或者在 Kibana &gt;“Dev Tools”（开发工具）下进行。
<h3>过度分片</h3>
数据索引<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html" target="_self">存储在子分片</a>中，这些子分片会在维护以及搜索/写入请求期间使用堆。分片大小的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/size-your-shards.html#shard-size-recommendation" target="_self">上限应设为 50GB</a>，数量上限应设为<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/size-your-shards.html#shard-count-recommendation" target="_self">通过以下公式确定的值</a>：<pre class="prettyprint">shards = sum(nodes.max_heap) * 20 </pre>
以上面的 Elasticsearch Service 为例，在两个区域中具有 8GB 的物理内存（将总共分配两个节点）<pre class="prettyprint">#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 </pre>
然后将这个结果与 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-allocation.html" target="_self">_cat/allocation</a> 进行交叉比较<pre class="prettyprint">GET /cn/_cat/allocation?v=true&amp;h=shards,node shards node 41 instance-0000000001 41 instance-0000000000 </pre>
或者以 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html" target="_self">_cluster/health</a> 作为比较对象<pre class="prettyprint">GET /cn/_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 } </pre>
因此，这个部署有 82 个分片，而建议最多可有 160 个分片。如果计数高于建议值，则您可能会遇到接下来两个部分中介绍的症状（请见下文）。
如果有任何分片报告（active_shards 或 active_primary_shards 除外）数字大于 0，那么您就找到了导致性能问题的主要配置原因。
如果这方面报告了问题，最常见的情况将是 unassigned_shards&gt;0。如果这些分片是主要分片，则集群将报告状态：红色；如果只是副本分片，它将报告状态：黄色。（这就是<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html#dynamic-index-settings" target="_self">在索引上设置副本分片</a>的重要之处，这样一来，如果集群遇到问题，它可以恢复数据而避免数据丢失。）
假设我们有一个状态：黄色，带有一个未分配的分片。为了进行调查，我们将通过 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-shards.html" target="_self">_cat/shards</a> 来查看哪个索引分片出现问题<pre style="white-space: pre;display: -webkit-box;" class="prettyprint">GET _cat/shards?v=true&amp;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 </pre>
因此，这将会用到我们的非系统索引日志，因为这个日志有一个未分配的副本分片。让我们运行一下 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.12/cluster-allocation-explain.html" target="_self">_cluster/allocation/explain</a> 来看看是什么导致了问题（专业提示：如果您向支持部门上报问题，我们做的就是这个操作）<pre style="white-space: pre;display: -webkit-box;" class="prettyprint">GET _cluster/allocation/explain?pretty&amp;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]" }]}]} </pre>
这个错误消息指向 data_hot，它是<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html" target="_self">索引生命周期管理</a> (ILM) 策略的一部分，并指明我们的 ILM 策略与当前的索引设置不一致。在本例中，这个错误的原因是在没有指定热温节点的情况下设置了热温 ILM 策略。（我需要保证让某些操作出现失败，以便为大家强行展示错误示例。看看你们对我都做了些什么😂。）
顺便说一下：如果您在没有任何未分配分片的情况下运行这个命令，则会出现 400 错误，提示找不到任何未分配的分片进行解释，因为没有错误要报告。
如果您遇到非逻辑原因（例如，分配期间节点离开群集等临时网络错误），则可以使用 Elastic 方便好用的 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html" target="_self">_cluster/reroute</a>。
<pre class="prettyprint">POST /cn/_cluster/reroute </pre>

这个无需定制的请求可启动一个异步后台进程，以尝试分配所有当前状态为 UNASSIGNED 的分片。（千万不要像我一样，不等它完成就联系开发人员；我原以为它瞬间就可以完成，上报时他们正好可以说什么错误都没有，因为什么问题都消失了。）
<h3>熔断器</h3>
最大限度地增加堆分配可能会导致对集群的请求发生超时或出错，并且会经常导致集群出现熔断器异常。熔断器会导致类似以下的 elasticsearch.log 事件：<pre class="prettyprint">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] </transport_request></pre>
要进行调查，请查看您的 heap.percent，方法是查看 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-nodes.html" target="_self">_cat/nodes</a><pre class="prettyprint">GET /cn/_cat/nodes?v=true&amp;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 </pre>
或者，如果您先前已启用它，也可以通过导览至 Kibana &gt;“Stack Monitoring”（堆栈监测）来进行调查。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb3f4f2c5cdb2823c/608322c4eed217453bf28487/blog-elasticsearch-memory-2.png" data-sys-asset-uid="bltb3f4f2c5cdb2823c" alt="blog-elasticsearch-memory-2.png" />
如果您确认将会触发内存熔断器，则可以考虑临时增加堆容量，为自己腾出空间进行调查。在调查根本原因时，请通过集群代理日志或 elasticsearch.log 查找先前的连续事件。您要寻找的是
<ul>
 <li aria-level="1">最耗费资源的查询，尤其是：<ul>
 <li aria-level="2">高存储桶聚合<ul>
 <li aria-level="3">&nbsp;当我发现搜索在运行查询之前会根据搜索大小或存储桶维度临时分配堆的某个端口时，我感到非常傻，所以设置 10,000,000 确实让我的运营团队感到非常沮丧。</li>
 </ul>
 </li>
 <li aria-level="2">非优化的映射<ul>
 <li aria-level="3">第二个让我感到愚蠢的原因是，我认为进行分层报告会比扁平化的数据搜索更好（其实不然）。</li>
 </ul>
 </li>
 </ul>
 </li>
 <li aria-level="1">请求量/速度：通常是批量或异步查询</li>
</ul>
<h3>进行扩展的时间</h3>
如果这不是您第一次触发熔断器，或者您怀疑这会是一个持续存在的问题（例如，堆利用率持续保持在 85％，那么就是考虑扩展资源的时候了）；您需要仔细看一下作为长期堆指示器的 <a href="https://www.elastic.co/cn/blog/found-understanding-memory-pressure-indicator" target="_self">JVM 内存压力</a>情况。您可以在 Elasticsearch Service &gt;“Deployment”（部署）中<a href="https://www.elastic.co/guide/en/cloud/current/ec-memory-pressure.html" target="_self">进行查看</a>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt42b0179b9a3b7782/608323041cac355a10f6d157/blog-elasticsearch-memory-3.png" data-sys-asset-uid="blt42b0179b9a3b7782" alt="blog-elasticsearch-memory-3.png" />
或者，您也可以根据 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html" target="_self">_nodes/stats</a> 信息进行计算，<pre class="prettyprint">GET /cn/_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 }}}}}}} </pre>
其中<pre class="prettyprint">JVM Memory Pressure = used_in_bytes / max_in_bytes </pre>
这种情况的一个潜在症状是：elasticsearch.log 中的垃圾收集器 (gc) 事件发生的频率高且持续时间长<pre class="prettyprint">[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s] </pre>
如果您确认是这种情况，就需要考虑一下，要么扩展集群，要么减少对集群的需求。您需要调查/考虑：
<ul>
 <li aria-level="1">增加堆资源（堆/节点，节点数）</li>
 <li aria-level="1">减少分片（删除不必要的/旧的数据，<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html" target="_self">使用 ILM</a> 将数据放入<a href="https://www.elastic.co/cn/blog/hot-warm-architecture" target="_self">温/冷存储</a>中，以便<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-shrink.html" target="_self">缩小数据</a>，对于无需担心丢失问题的数据，关闭副本分片）</li>
</ul>
<h2>结论</h2>
哇！从我在 Elastic 支持中见到的情况来看，用户提交的工单中最常见问题包括：未分配的分片、不平衡的分片堆、熔断器、大量垃圾收集和分配错误。所有这些都是核心资源分配管理对话的症状。希望您现在也对相关理论和解决步骤有了一些了解。
不过，如果您现在仍无法解决问题，请随时与我们联系。我们将竭诚为您提供帮助！您可以通过 <a href="http://discuss.elastic.co/" target="_self">Elastic Discuss</a>、<a href="https://join.slack.com/t/elasticstack/shared_invite/zt-o4sdlhb7-OGXEcy4iry_CsxVyJLGYag" target="_self">Elastic 社区 Slack</a>、咨询、培训和支持团队与我们联系。
为我们能够作为非运维人员（以及热爱运维的人）自行管理 Elastic Stack 资源分配欢呼！

blog-banner-circuit-buildings.jpg

blog-thumb-circuit-buildings.jpg

Managing and troubleshooting Elasticsearch memory

管理 Elasticsearch 内存并进行故障排查

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Stef Nestor

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/elastic-cloud-account-terms" target="_self">服务条款</a>，并且您同意通过您提供的上述联系方式接收<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">所选的通信</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/serverless-preview-terms" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

提交即表示您同意 <a href="/cn/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 服务条款</a>。我们将会按照 <a href="/cn/legal/privacy-statement">Elastic 的隐私声明</a>处理您的个人数据。

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

提交即表示您确认您已阅读并同意我们的<a href="/cn/legal/terms-of-use" target="_self">服务条款</a>，并且 Elastic 可以使用您提供的上述详细信息与您联系，以向您介绍我们相关的<a href="/cn/legal/privacy-statement#how-we-use-the-information" target="_self">产品和服务</a>。如需了解更多信息，或想随时取消订阅，请参阅 <a href="/cn/legal/privacy-statement/" target="_self">Elastic 的隐私声明</a>。

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

本页内容尚不支持所选语言。Elastic 正在不断努力，以实现对多种语言内容的支持。感谢您在此期间给予的耐心与陪伴！

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

查看本次网络研讨会在我的时区的开始时间

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

无法实时参加？注册后我们会给您发送录像。您还将收到相关内容的电子邮件。

Author

Articles by Stef Nestor

管理 Elasticsearch 内存并进行故障排查

Sign up for Elastic Cloud free trial