如何识别和解决分片过多的集群运行状况问题？

简短描述

每个分片都会消耗一定量的 CPU/JVM 资源进行维护。当分片过多时，您可能会看到集群性能严重下降。在某些分片过多的情况下，整个集群可能会变得无响应。

为确保集群运行正常且按预期运行，请遵循 OpenSearch Service 最佳实践。

分片过多的症状

如果集群有以下一个或多个症状，请完成解决步骤。要验证域是否受到过多分片的影响，请查看集群运行状况指标随时间的变化趋势。

• 每个节点超过 1,000 个分片。
• 每个分片大小小于 10 GB 的索引。
• 节点持续丢弃。
• 高 JVM/CPU 资源指标。
• 蓝绿部署的复杂性。
• 集群状态对于所选主节点来说非常难以处理。
• 正在使用 T 实例类型。或者，正在使用较小的实例类型。例如，正在使用实例类型 c5.large。

解决方法

查看域趋势

使用 3/6/12/14 个月范围来查看域的 Amazon CloudWatch 指标。如果分片创建定期发生，则增加图表的时间段。否则，您将无法看到完整的运行状况趋势历史记录。**注意：**您必须将指标周期更改为 1 小时，以便指标在更长的时间范围内正确加载。

在分片过多的域中会发生以下情况：

• Shards.active 计数增加。在分片数量超过每个节点 1000 个分片之后，当集群面临流量增加时，集群的运行状况就会受到威胁。当来自搜索请求的流量在增加的分片数量上发生时，这种风险就会增加。
• 当集群的节点指标在最小值/最大值/平均值统计数据中不是实线时，就会发生节点丢弃。当达到 JVM 内存限制时，OpenSearch Service 进程无法在节点上运行。然后，托管服务会自动重启该进程。
• JVMMemoryPressure 增加。随着 G1 垃圾回收（G1GC）变得更加频繁且效率降低，最小值/平均值/最大值会收敛。理想状态下，该指标以锯齿模式在 0-75% 之间波动。如果 JVMMemoryPressure 在加剧时突破 75%，并且平均 JVMMemoryPressure 突破 75%，则会发生初始影响。有关 OpenSearch Service 中的 JVM 和垃圾回收的更多信息，请参阅 Understanding the JVMMemoryPressure metric changes in Amazon OpenSearch Service。有关更多信息，请参阅如何解决 OpenSearch Service 集群上的高 JVM 内存压力问题？
• CPUUtilization 增加。集群花费更多资源和时间来对其维护的分片进行垃圾回收。

排查分片过多问题

要排查分片过多问题，请选择以下解决方法之一：

减少分片数量

OpenSearch 最佳实践是根据可用的 JVM 堆内存限制每个节点的分片数量。确保每 GiB JVM 堆的分片不超过 20-25 个。在 OpenSearch 托管服务中，JVM 堆的大小限制为 32 GiB。此限制意味着每个节点最多可以有 640-800 个分片。每个节点的分片数量限制为 1,000 个，可以通过集群设置进行修改。

如果不需要数据，则删除较旧索引。在删除较旧索引数据之前，请手动创建其快照。

在 ISM 中使用轮换索引时，请注意下面几点：

• 检查您的分片策略是否将索引置于最佳实践分片大小范围内（10-50gb）。例如，假设您使用每日 ISM 索引和默认 5:1 分片。这种做法的结果是每天产生 10 个分片，每月最多产生 300 个分片。
• 使用索引模板来减少较小每日索引的分片数量。有关更多信息，请参阅 OpenSearch 网站上的 Index templates。请注意，这仅影响集群中新创建的索引，不会立即改善集群运行状况。
• 使用重新索引 OpenSearch API 将旧的每日和每周索引合并为每月索引。有关更多信息，请参阅 OpenSearch 网站上的 Combine one or more indexes。然后，更改 ISM 索引的轮换周期，以避免创建太小的指数。

扩展实例

请注意以下几点：

• 纵向扩展或横向扩展不是一个可行的长期解决方案。请务必遵循 OpenSearch Services 最佳实践。
• 当您纵向扩展实例类型时，每个节点的可用资源以及该节点可处理的分片总数都会增加。
• 当您横向扩展数据节点计数时，每个节点的分片数量会减少。这种减少减轻了对其他节点的影响。

相关信息

OpenSearch 网站上的 Optimize OpenSearch index shard sizes