随着受众越来越多，我看到了更多管理资源分配方面的问题，特别是神秘的shard heap 比率以及如何避免使用熔断器的问题。我很能理解他们的顾虑，当我开始使 用Elastic Stack时，我也有过同样的疑问。这是我第一次详细介绍Java堆和时间序 列数据库分片管理，以及我是如何扩展自己的基础架构的。
当我刚加入Elastic团队时，我很喜欢Elastic的一点是，除了文档之外，我们还有 博客和教程，让我很快就能上手。但是在第一个月，我努力将我的理论知识与用户 发来的报错信息联系起来，最终，像其他支持工程师一样，我发现很多报错实质上 只是分配问题，使用同样的七个链接就可以快速让用户将他们的资源分配成功地管 理起来。
作为支持工程师，在以下各节中，我将介绍我们发送给用户的最重要的分配管理理 论链接、常见表现特征，以及我们是如何指导用户通过更新配置来解决资源分配的。
1. 理论
作为一个Java应用程序，Elasticsearch需要从系统的物理内存中分配一些逻辑内 存（堆）这应该最多是物理RAM的一半，上限为32GBO设置较高的堆使用率通常 是为了应对开销较大的查询和更大的数据存储。父级熔断器默认值为95%,但我们 建议在持续达到85%时就扩展资源。
2. 配置
开箱即用，Elasticsearch的默认设置会根据节点角色和总内存自动调整JVM堆的大 小。不过您也可以在需要时通过以下三种方式直接配置：
1）直接在本地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) 作为 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
3) 通过我们的 Elasticsearch Service>Deployment>Edit view。注意：由滑块 分配物理内存，大约一半将分配给堆。
3. 故障排除
如果您的集群目前遇到了性能问题，这很可能是因为一些常见的原因:
• 配置问题：分片过多，无ILM策略；
• 量引起的：请求速度高、负载高，重叠昂贵的查询/写入重叠。
以下所有 cURL/API 请求均可作为 Elasticsearch API 的 cURL 在 Elasticsearch 服 务〉API控制台，或在Kibana>开发工具下提出。
4. 分片过多
数据索引存储在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 { II I I II II II status : green , "unassigned_shardsH: 0, "initializing_shardsH: 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>0o如果这些shard 是主要分片，您的集群将报告"状态：红色"，如果只是副本，则报告为"状态： 黄色"（所以在索引上设置副本很重要，这样，在集群遇到问题时可以恢复，不会丢失数据）。
假设我们有一个"状态：黄色'’和一个未指派的shard。为了进行调查，我们将利 用_cat/shards来查看是哪个索引分片出现了问题。
这将用于我们的非系统索引日志，它有一个未指派的副本分片。让我们运行 _cluster/allocation/explain来看看问题出在哪儿：专业提示：当您升级到支持时，这正 是我们所做的事情）
此错误消息指向data_hot，它是索引生命周期管理（ILM）策略的一部分，说明我 们的ILM策略与当前的索引设置不一致。在本例中，此错误的原因是在没有指定hot- warm的情况下设置了 hot-warm ILM策略（我必须让一些东西出错，因为这是我在给你 们演示错误示例。看看你们对我做了什么）。
仅供参考，如果没有unsigned shards情况下就运行此命令，将会出现一个400错 误：当前已没有未指派到节点的分片，因为没有任何错误报告。
如果您遇到非逻辑原因（例如，在分配期间节点离开集群之类的临时网络错误，您可以随 时使用 Elastic 的_cluster/reroute。
POST /_cluster/reroute
这一无需定制的请求将启动一个异步后台进程，尝试分配所有当前状态： NASSIGNED shards （别像我一样等到它完成后才联系开发人员，我当时以为这是瞬间的，而 且可以很巧地为他们及时完成升级，然后告诉他们一切正常，因为什么都没有了）
5. 熔断器
最大化堆分配可能会引起对集群的请求超时或错误，而且，您的集群还会经常遇到 熔断器异常这一问题。熔断会导致elasticsearch.log事件，例如：
要进行调查，请查看您的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, 以此查找之前发生的连续事件。您需要查找：
1）昂贵的查询，尤其是：
• 高桶聚合
我发现，搜索在根据搜索大小或存储桶尺寸运行查询之前，临时分配了堆的某 个端口，我觉得这太傻了，就设置了 10,000,000.我的运维团队为此很挠头。
• 非优化映射
感到愚蠢的第二个原因是，我认为搜索时如果利用分层报告会比扁平化数据更 好（事实并非如此）。
2）请求量/速度
通常是批处理或异步查询。
6. 是时候扩容了
如果您已不止一次启动熔断机制，或者您觉得这个问题将一直存在（例如，始终达 到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将数据放入热/令存储中，之 后您就可以缩减数据，关闭那些即使丢失了您也不在乎的数据副本）。
7. 结论
哇！从我在Elastic Support中看到的情况来看，这是最常见的用户故障：未指派的 分片(unassigned shards)、不平衡的分片堆、熔断器、大量垃圾收集和分配错误。 所有这些都是核心资源分配管理会话的表现特征。但愿您现在已经掌握了理论和解 决的具体步骤。
说了这么多，如果您在解决问题时仍然遇到困难，请随时与我们联系。我们很乐意 为您提供帮助！您可以通过Elastic Discuss、Elastic Community Slack、咨询、培训 和支持服务与我们联系。
作为非运维人员，我们为自己有能力自管理Elastic Stack的资源分配感到U高兴！
