如何對 OpenSearch Service 叢集中的搜尋延遲高峰進行疑難排解？

簡短說明

對於搜尋請求，OpenSearch Service 使用以下公式計算往返時間：

**往返時間 = 查詢在查詢階段花費的時間 + 擷取階段的時間 + 佇列中的時間 + 網路延遲時間 **

Amazon CloudWatch 中的 OpenSearch Service 指標 SearchLatency 會顯示查詢在查詢階段花費的時間。

若要對 OpenSearch Service 叢集中的搜尋延遲高峰進行疑難排解，請採取以下措施：

• 檢查基礎結構指標，例如 CPU 使用率、磁碟使用率，以及 Java Virtual Machine (JVM) 記憶體壓力和垃圾回收的記憶體使用情況。
• 檢查 SearchRate 指標的高峰情況。
• 使用 ThreadpoolSearchRejected 指標檢查搜尋遭拒的情況。
• 使用慢速日誌辨識長時間執行的查詢。
• 解決「504 gateway timeout」錯誤。
• 最佳化您的組態以降低延遲。

解決方法

檢查基礎結構指標

當作業系統 (OS) 資料節點上的資源使用率較高時，可能會出現頻繁且長時間的垃圾回收。如果您的叢集未佈建足夠資源，可能會遇到搜尋延遲高峰。

對資源使用率過高問題進行疑難排解

確保叢集的 CPUUtilization 及 JVMMemoryPressure 指標低於 80%。如果 CloudWatch 中的指標值高於 80%，請對高 CPU 使用率或高 JVM 記憶體壓力問題進行疑難排解。

若要主動監控資源使用率，請為 OpenSearch Service 設定 CloudWatch 警示。

若要取得叢集的節點層級統計資訊，請每隔 5 分鐘多次執行下列查詢：

GET /_nodes/stats

在輸出中，檢查快取使用率、fielddata 記憶體 以及 JVM heap 值在各次執行之間的重大變化。穩定的值表示運作正常。若出現突增或突降，可能表示有問題。

檢查您的快取設定

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。

對包含高度唯一值的欄位進行彙總可能會導致堆積使用率增加。彙總查詢的搜尋操作會使用 fielddata。Fielddata 也會排序和存取指令碼中的欄位值。Fielddata 移出取決於 indices.fielddata.cache.size 檔案的大小，此檔案占 JVM 堆積的 20%。

若要檢查整個叢集中 fielddata 使用了多少記憶體，請執行以下查詢：

GET /_nodes/stats/indices/fielddata?human

檢查 SearchRate 指標的高峰情況

在短時間內的多次搜尋請求可能會造成叢集資源緊張，導致查詢處理延遲及單次搜尋回應時間變慢。OpenSearch Service 中的高搜尋率可能會導致搜尋延遲增加。如果 SearchRate 指標出現高峰，請檢查這些高峰是否與搜尋延遲高峰同時發生。如果高峰同時發生，則必須增加叢集資源或最佳化查詢，以管理搜尋負載。

檢查搜尋遭拒

使用 ThreadpoolSearchRejected 指標來識別並解決搜尋遭拒問題。

使用慢速日誌識別長時間執行的查詢

若要識別長時間執行的查詢，以及查詢在特定碎片上的執行時間，請使用慢速日誌。您可以為查詢階段設定閾值，然後為每個索引設定擷取階段。

若要詳細總結查詢在查詢階段所花費的時間，請在搜尋查詢中將設定檔設定為 true。

查詢範例：

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

注意：如果您將日誌閾值設定過低，JVM 記憶體壓力及叢集延遲可能會增加。當您記錄更多查詢時，也會增加成本。對於將設定檔設定為 true 的查詢，其輸出量過大會增加其他搜尋查詢的額外負擔。因此，其他搜尋會暫時變慢。

解決 504 gateway timeout 錯誤

先決條件：啟用錯誤日誌以識別特定 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。此外，請確保碎片大小介於 10 GiB 到 50 GiB 之間。最佳實務是將節點上碎片的最大數量設為堆疊大小的 20 倍。如需如何重新索引和變更碎片段策略的資訊，請參閱 OpenSearch 網站上的最佳化 OpenSearch 索引片段大小。

過多區段或過多已刪除的文件也會影響搜尋效能。為了提升效能，請對唯讀索引使用強制合併，並增加活動索引的重新整理間隔。如需更多資訊，請參閱 OpenSearch 網站上的強制合併 API 與最佳化 OpenSearch 重新整理間隔。

在將複本碎片新增到所有節點前，請先評估您的應用程式需求。如果您的應用程式必須能從任意節點搜尋所有資料，請增加複本碎片數量以提升資料可用性。否則，您可能不需要在每個節點上都配置複本碎片。

**注意：**複本碎片允許叢集使用平行處理，並將搜尋請求分散到資料的多個複本。因此可搜尋效能提升。然而，索引操作會變慢，且每份完整資料複本都需要額外儲存空間。

對於擁有大量碎片的索引，請使用自訂路由以改善搜尋效能。使用自訂路由時，您只查詢存放資料的碎片，而非所有碎片。有關設定自訂路由，請參閱 Elastic 網站上的自訂文件路由。

對唯讀資料使用 UltraWarm 儲存空間

熱儲存空間提供對新資料索引與搜尋的最快效能。然而，UltraWarm 節點提供具有成本效益的方法，在叢集上儲存大量唯讀資料。對於不需要高效能的唯讀索引，請使用 UltraWarm 取代熱資料儲存空間。

提升搜尋速度

搜尋盡可能少的欄位，並避免使用指令碼與萬用字元查詢。如需更多資訊，請參閱 Elastic 網站上的調整搜尋速度。