如何解决 Amazon OpenSearch Service 集群中的搜索延迟峰值问题？

2 分钟阅读

我的 Amazon OpenSearch Service 集群出现了搜索延迟峰值。

简短描述

对于搜索请求，OpenSearch Service 按如下方式计算往返时间：

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

Amazon CloudWatch 上的 SearchLatency 指标为您提供在查询阶段所花费的查询时间。

要解决 OpenSearch Service 集群中的搜索延迟峰值问题，您可以采取多个步骤：

检查集群上预调配的资源是否不足
使用 CloudWatch 中的 ThreadpoolSearchRejected 指标检查搜索拒绝
使用搜索慢速日志 API 和配置文件 API
解决所有 504 网关超时错误

解决方法

检查集群上预调配的资源是否不足

如果您在集群上预调配的资源不足，则可能会遇到搜索延迟峰值。使用以下最佳实践来确保您预调配了足够的资源。

1. 使用 CloudWatch 查看集群的 CPUUtilization 指标和 JVMMemory 压力。确认它们在建议的阈值之内。有关详细信息，请参阅针对 Amazon OpenSearch Service 的建议 CloudWatch 警报。

2. 使用节点统计信息 API 获取集群的节点级别统计信息：

GET /_nodes/stats

在输出中，检查以下部分：caches、fielddata 和 jvm。要比较输出，请多次运行此 API，每个输出之间会有一定的延迟。

3. OpenSearch Service 使用多个缓存来改进其性能和请求的响应时间：

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

查看缓存驱逐的节点统计信息 API 输出。输出中的大量缓存驱逐意味着缓存大小不足以满足请求。要减少驱逐，请使用具有更多内存的更大型节点。

要使用节点统计信息 API 查看特定的缓存信息，请使用以下请求。第二个请求针对分片级别的请求缓存：

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

有关 OpenSearch 缓存的详细信息，请参阅 Elastic 网站上的 Elasticsearch 缓存深入研究：提高查询速度，一次只能使用一个缓存。

有关清除各种缓存的步骤，请参阅 OpenSearch 网站中的清除索引或数据流缓存。

4. 对包含高度唯一值的字段执行聚合可能会导致堆使用量增加。如果聚合查询已在使用中，则搜索操作将使用字段数据。字段数据还对脚本中的字段值进行排序和访问。字段数据驱逐取决于indices.fielddata.cache.size 文件的大小，这占 JVM 堆空间的 20%。当超过缓存时，驱逐开始。

要查看字段数据缓存，请使用以下请求：

GET /_nodes/stats/indices/fielddata?human

有关解决高 JVM 内存问题的详细信息，请参阅如何解决 Amazon OpenSearch Service 集群上的高 JVM 内存压力问题？
要解决高 CPU 利用率问题，请参阅如何解决我的 Amazon OpenSearch Service 集群上 CPU 利用率较高的问题？

使用 CloudWatch 中的 ThreadpoolSearchRejected 指标检查搜索拒绝

要使用 CloudWatch 检查搜索拒绝，请按照如何解决 Amazon OpenSearch Service 中的搜索或写入拒绝？中的步骤进行操作。

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

要识别长时间运行的查询和查询在特定分片上花费的时间，请使用慢速日志。您可以为查询阶段设置阈值，然后为每个索引提取该阶段。有关设置慢速日志的详细信息，请参阅查看 Amazon Elasticsearch 服务慢速日志。要详细了解您的查询在查询阶段所花费的时间，请为您的搜索查询设置 "profile":true。

**注意：**如果将日志记录阈值设置为非常低的值，则您的 JVM 内存压力可能会增加。这可能会导致更频繁的垃圾回收，从而增加 CPU 使用率并增加集群延迟。记录更多查询也可能会增加您的成本。配置文件 API 的长输出还会给任何搜索查询增加大量开销。

解决所有 504 网关超时错误

从您的 OpenSearch Service 集群的应用程序日志中，您可以看到单个请求的特定 HTTP 错误代码。有关解决 HTTP 504 网关超时错误的详细信息，请参阅如何防止 Amazon OpenSearch Service 中的 HTTP 504 网关超时错误？

**注意：**必须激活错误日志才能识别特定的 HTTP 错误代码。有关 HTTP 错误代码的详细信息，请参阅查看 Amazon OpenSearch Service 错误日志。

其他可能导致高搜索延迟的因素

还有许多其他因素可能导致高搜索延迟。使用以下提示进一步解决高搜索延迟问题：

频繁或长时间运行的垃圾回收活动可能会导致搜索性能问题。垃圾回收活动可能会暂停线程并增加搜索延迟。有关详细信息，请参阅 Elastic 网站上的堆问题：管理 Amazon OpenSearch Service 的托管堆。
预调配 IOPS（或 i3 实例）可以帮助您消除任何 Amazon Elastic Block Store（Amazon EBS）瓶颈。大多数情况下，您并不需要它们。在将实例移至 i3 之前，最佳实践是测试 i3 节点和 r5 节点之间的性能。
分片过多的集群可能会增加资源利用率，即使集群处于非活动状态也是如此。分片过多会降低查询性能。虽然增加副本分片数量可以帮助您提高搜索速度，但在某个给定节点上不要超过 1000 个分片。此外，请确保分片大小介于 10 GiB 和 50 GiB 之间。理想情况下，一个节点上的最大分片数为堆 * 20。
分段过多或已删除文档过多可能会影响搜索性能。为了提高性能，请在只读索引上使用强制合并。此外，如果可能，请增加活跃索引的内部刷新次数。有关详细信息，请参阅 Elastic 网站上的 Lucene 对已删除文档的处理。
如果您的集群位于虚拟私有云（VPC）中，则最佳实践是在同一 VPC 中运行应用程序。
使用 UltraWarm 节点或热数据节点存储只读数据。热存储可最大限度提高索引和搜索新数据的速度。但是，UltraWarm 节点是在集群上存储大量只读数据的一种经济高效的方式。对于无需写入数据且不需要高性能的索引，UltraWarm 可显著降低每 GiB 数据的成本。
确定在所有节点上提供您正在搜索的数据是否有益于您的工作负载。某些应用程序会从这种方法中受益，尤其是在集群上的索引很少的情况下。为此，请增加副本分片的数量。
**注意：**这可能会增加索引延迟。此外，您可能需要额外的 Amazon EBS 存储空间来容纳您添加的副本。这会增加您的 EBS 卷成本。
搜索尽可能少的字段，避免使用脚本和通配符查询。有关详细信息，请参阅 Elastic 网站上的调整搜索速度。
对于分片较多的索引，请使用自定义路由来帮助加快搜索速度。自定义路由可确保您仅查询保存数据的分片，而不是将请求广播到所有分片。有关详细信息，请参阅 Elastic 网站上的自定义您的文档路由。