如何对 OpenSearch Service 集群中的搜索延迟峰值问题进行故障排除？

简短描述

对于搜索请求，OpenSearch Service 使用以下公式计算往返时间：

往返时间 = 查询在查询阶段的耗时 + 在获取阶段的耗时 + 在队列中的耗时 + 网络延迟

Amazon CloudWatch 中的 SearchLatency OpenSearch Service 指标显示查询阶段所花费的查询时间。

要对 OpenSearch Service 集群中的搜索延迟峰值问题进行故障排除，请执行以下操作：

• 检查基础设施指标，例如 CPU 使用率、磁盘使用率以及 Java 虚拟机 (JVM) 内存压力和垃圾回收相关内存指标。
• 检查 SearchRate 指标中是否出现峰值。
• 使用 ThreadpoolSearchRejected 指标检查是否存在搜索拒绝。
• 使用慢速日志来识别长时间运行的查询。
• 解决 "504 gateway timeout" 错误。
• 优化您的配置以减少延迟。

解决方法

检查基础设施指标

当您的资源使用率较高时，操作系统 (OS) 数据节点上会进行频繁且耗时的垃圾回收操作。如果您未在集群上预置足够的资源，则可能会遇到搜索延迟峰值。

对高资源使用率进行故障排除

确保集群的 CPUUtilization 和 JVMMemoryPressure 指标低于 80%。如果 CloudWatch 中的指标值高于 80%，请对高 CPU 使用率或高 JVM 内存压力进行故障排除。

要主动监控资源使用情况，请为 OpenSearch Service 设置 CloudWatch 警报。

要获取集群的节点级统计数据，请每隔 5 分钟多次运行以下查询：

GET /_nodes/stats

在输出中，查看各次运行之间 cache usage（缓存使用率）、fielddata memory（字段数据内存）和 JVM heap（JVM 堆）值是否存在显著变化。值稳定表明运行正常。出现突然的峰值或骤降表示可能存在问题。

检查您的缓存设置

OpenSearch Service 使用以下缓存来改进其性能和请求响应时间：

• 存在于操作系统级别的文件系统缓存或页面缓存
• 存在于 OpenSearch Service 级别的分片级请求缓存和查询缓存

要查看文件系统缓存的信息，请运行以下查询：

GET /_nodes/stats/indices/request_cache?human

要查看分片级请求缓存的信息，请运行以下查询：

GET /_nodes/stats/indices/query_cache?human

在输出中，检查是否存在缓存驱逐。缓存驱逐次数过多意味着缓存过小，无法满足请求。要减少驱逐，请使用具有更多内存的更大型节点。有关节点大小定价的详细信息，请参阅 OpenSearch Service 定价。有关 OpenSearch 缓存的详细信息，请参阅 Elastic 网站上的 Elasticsearch 缓存深度剖析： 一次提高一种缓存的查询速度。

要清除缓存，请参阅 OpenSearch 网站上的清除缓存 API。

对包含高度唯一值的字段执行聚合可能会导致堆使用量增加。聚合查询的搜索操作使用字段数据。字段数据还会对脚本中的字段值进行排序和访问。字段数据驱逐取决于 indices.fielddata.cache.size 文件的大小，该文件占 JVM 堆内存的 20%。

要检查集群中所有节点的字段数据使用的内存量，请运行以下查询：

GET /_nodes/stats/indices/fielddata?human

检查 SearchRate 指标中是否出现峰值

短时间内多个搜索请求会导致集群资源紧张，进而导致查询处理延迟，以及单个搜索的响应时间变慢。OpenSearch Service 中的搜索率过高会导致搜索延迟增加。如果 SearchRate 指标出现峰值，请检查该峰值是否与搜索延迟峰值同时出现。如果峰值同时出现，则必须向集群添加更多资源，或优化查询以管理搜索负载。

检查是否存在搜索拒绝

使用 ThreadpoolSearchRejected 指标来识别并解决搜索拒绝问题。

使用慢速日志来识别长时间运行的查询

要识别长时间运行的查询以及某个查询在特定分片上的耗时，请使用慢速日志。您可以为每个索引的查询阶段和获取阶段依次设置阈值。

要获取查询在查询阶段所花费时间的详细汇总，请在搜索查询中将 profile 设置为 true。

查询示例：

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

**注意：**如果您将日志记录阈值设置得过低，则您的 JVM 内存压力和集群延迟可能会增加。当记录更多查询时，您的成本也会增加。如果 profile 设置为 true 的查询的输出较大，则会增加其他搜索查询的开销。从而导致其他搜索暂时变慢。

解决 504 网关超时错误

先决条件：激活错误日志以识别特定的 HTTP 错误代码。

使用您的 OpenSearch Service 集群的应用程序日志来检查单个请求的特定 HTTP 错误代码。要解决 HTTP 504 网关超时错误，请参阅如何防止 OpenSearch Service 中出现 HTTP 504 网关超时错误？

优化您的配置

管理您的垃圾回收活动

频繁或长时间运行的垃圾回收活动可能会导致搜索性能问题、线程暂停以及搜索延迟增加。有关减少垃圾回收时间的最佳实践，请参阅 Elastic 网站上的堆内存问题： 管理 Elasticsearch 的托管堆。

优化您的实例存储

您的 Amazon Elastic Compute Cloud (Amazon EC2) 实例类型可使用 Amazon Elastic Block Store (Amazon EBS) 优化存储或实例存储卷。实例存储卷可帮助解决 I/O 瓶颈，因为其提供直接附加的存储和更高的 IOPS 性能。但是，Amazon EBS 优化实例可提供具备稳定性能的持久性存储。请根据 I/O、数据持久性和成本选择符合您的配置要求的存储类型。

在更改实例类型之前，最佳做法是测试不同实例类型之间的性能，以验证其是否满足您的工作负载需求。有关可用的 OpenSearch Service 实例类型的列表，请参阅 OpenSearch Service 定价中的免费套餐和按需型实例定价。

**注意：**如果您的集群位于虚拟私有云 (VPC) 中，则最佳做法是在同一 VPC 中运行您的应用程序。

简化您的分片和分段配置

分片过多的集群可能会导致资源使用率增加，即使集群处于非活动状态也是如此。分片过多也会降低查询性能。尽管副本分片数量越大，搜索速度越快，但不要在单个节点上使用超过 1000 个分片。此外，请确保分片大小介于 10GiB 和 50GiB 之间。最佳做法是将节点上的最大分片数设置为堆大小的 20 倍。有关如何重新索引和更改分片策略的信息，请参阅 OpenSearch 网站上的优化 OpenSearch 索引分片大小。

分段过多或已删除文档过多可能会影响搜索性能。要提升性能，请对只读索引使用强制合并，并增加活动索引的刷新间隔。有关详细信息，请参阅 OpenSearch 网站上的强制合并 API 和优化 OpenSearch 刷新间隔。

在向所有节点添加副本分片之前，请评估您的应用程序的需求。如果应用程序必须从任意节点搜索所有数据，请增加副本分片的数量以提高数据可用性。否则，无需在每个节点上都配置副本分片。

**注意：**副本分片允许集群使用并行处理并将搜索请求分发至多个数据副本。从而使搜索性能得到提升。但是，索引操作会变慢，且每个完整的数据副本都需要额外的存储空间。

对于分片较多的索引，请使用自定义路由来提升搜索性能。使用自定义路由时，只会查询保存您的数据的分片，而非所有分片。要配置自定义路由，请参阅 Elastic 网站上的自定义您的文档路由。

对只读数据使用 Ultrawarm 存储

热存储可提供最快的新数据索引和搜索性能。但是，UltraWarm 节点是在集群上存储大量只读数据的一种经济高效的方式。对于无需高性能的只读索引，请使用 UltraWarm 替代热数据存储。

提高搜索速度

搜索尽可能少的字段，避免使用脚本和通配符查询。有关详细信息，请参阅 Elastic 网站上的调整搜索速度。