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

上次更新日期:2021 年 8 月 5 日

我在 Amazon OpenSearch Service (Amazon Elasticsearch Service 的後繼者) 叢集中遇到搜尋延遲峰值的問題。如何疑難排解及解決搜尋延遲峰值的問題?

簡短描述

對於搜尋請求,往返時間的計算方式如下:

Round trip = Time the query spends in the query phase + time in the fetch phase + time spent in the queue + network latency

Amazon CloudWatch 上的 SearchLatency 指標讓您能知道查詢階段所花費的時間。

您可以採取許多疑難排解步驟來針對 OpenSearch Service 叢集中的延遲峰值問題進行疑難排解,包括:

  • 檢查叢集上佈建的資源是否不足
  • 使用 CloudWatch 中的 ThreadpoolSearchRejected 指標來檢查搜尋拒絕
  • 使用搜尋慢速日誌和設定檔 API
  • 解決任何 504 閘道逾時錯誤

解決方案

檢查叢集上佈建的資源是否不足

如果叢集上佈建的資源不足,您可能會遇到搜尋延遲峰值的問題。請使用下列最佳實務來確保您已佈建足夠的資源。

1.    使用 Amazon CloudWatch 檢閱 CPU 使用率指標和叢集的 JVMMemory 壓力,以確認它們在建議的閾值範圍內。如需詳細資訊,請參閱建議的 CloudWatch 警示

2.    使用節點統計 API 來取得叢集上的節點層級統計數字:

GET /_nodes/stats

在輸出中檢查以下部分:快取,fielddata 和 jvm。多次執行此 API 並延遲比較輸出。

3.    OpenSearch Service 使用檔案系統快取來提出更快的搜尋請求。檢閱快取移出的節點統計 API 輸出。輸出中有大量的快取移出表示快取大小不足以滿足請求。在這種情況下,請考慮使用具有更多記憶體的更大節點。

4.    在包含高度唯一值的欄位上執行彙總可能會導致堆積用量增加。如果彙總查詢已在使用中,則搜尋作業會使用 FieldData。FieldData 也可用來排序和存取指令碼中的欄位值。FieldData 移出取決於 indices.fielddata.cache.size 檔案的大小,這佔了 20% 的 JVM 堆積空間。超過快取時,就會開始移出。

如需有關疑難排解高 JVM 記憶體的詳細資訊,請參閱如何疑難排解 Amazon OpenSearch Service 叢集上的高 JVM 記憶體壓力?

若要疑難排解高 CPU 使用率,請參閱如何疑難排解 Amazon OpenSearch Service 叢集上的高 CPU 使用率?

使用 CloudWatch 中的 ThreadpoolSearchRejected 指標來檢查搜尋拒絕

若要使用 CloudWatch 檢查搜尋拒絕,請遵循 如何解決 Amazon OpenSearch Service 中的搜尋或寫入拒絕問題?中的步驟

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

使用慢速日誌來識別長時間執行的查詢和查詢花費在特定碎片上的時間。您可以設定查詢階段的閾值,然後擷取每個索引的階段。如需有關設定慢速日誌的詳細資訊,請參閱檢視 Amazon OpenSearch Service 慢速日誌。請務必為搜尋查詢設定 "profile":true,以取得查詢在查詢階段所花費時間的明細。

注意:如果將日誌閾值設定為非常低的值,那麼您的 JVM 記憶體壓力可能會增加。這可能會導致更頻繁的廢棄項目收集,然後增加 CPU 使用率並增加叢集的延遲。記錄更多查詢也會增加您的成本。設定檔 API 的輸出可能會很長,讓搜索查詢的費用明顯增加。

解決任何 504 閘道逾時錯誤

在 OpenSearch Service 叢集的應用程式記錄中,您可以查看個別請求的特定 HTTP 錯誤代碼。如需解決 HTTP 504 閘道逾時錯誤的詳細資訊,請參閱如何預防在 Amazon OpenSearch Service 中的 HTTP 504 閘道逾時錯誤?

注意:您必須啟用錯誤日誌才能識別特定的 HTTP 錯誤代碼。如需 HTTP 錯誤代碼的詳細資訊,請參閱檢視 Amazon OpenSearch Service 錯誤日誌

其他可能會造成高搜尋延遲的因素

還有許多其他因素可能會造成高搜尋延遲。請使用下列秘訣來進一步疑難排解高搜尋延遲:

  • 頻繁或長時間執行的廢棄項目收集活動可能會造成搜尋效能問題。廢棄項目收集活動可以暫停執行緒,並增加搜尋延遲。如需詳細資訊,請參閱 Elasticsearch 網站上的管理 Elasticsearch 上已管理的堆積
  • 佈建 IOPS (或 i3 執行個體) 可能會幫助您移除任何 Amazon Elastic Block Store (Amazon EBS) 瓶頸。在大多數情況下,您不會需要它們。在直接移動到 i3 之前,測試 i3 節點和 r5 節點之間的效能是最佳實務。
  • 具有太多碎片的叢集可能會導致資源使用率增加,即使叢集處於非作用中狀態。太多的碎片會降低查詢效能。雖然增加複本碎片計數可以幫助您實現更快的搜尋,但請確保您在給定節點上不會有 1000 個以上的碎片。此外,請確定碎片大小介於 10 GiB 和 50 GiB 之間。理想情況下,節點上的最大碎片數應該是堆積 * 20。
  • 過多的區段或太多刪除的文件會影響搜尋效能。在此情況下,在唯讀索引上使用強制合併會有幫助。如果您的使用案例允許,請增加活動索引上的重新整理內部。如需更多資訊,請參閱 Elasticsearch 網站上的Lucene 處理刪除文件的方法
  • 如果您的叢集位於 VPC 中,請考慮在同一個 VPC 中執行應用程式。
  • 請考慮使用 UltraWarm 節點或熱資料節點的唯讀資料。熱儲存提供索引和搜尋新資料的最快效能。不過,符合成本效益的作法是使用 UltraWarm 節點在叢集上儲存大量唯讀資料。對於您沒有主動寫入或不需要相同效能的索引,UltraWarm 可大幅降低每 GiB 資料的成本。
  • 請測試您的工作負載,看看當搜尋的資料可在所有節點上使用時是否有益於工作負載。某些應用程式受益於這種方法,特別是當叢集上的索引很少時。若要執行這項操作,請增加複本碎片的數目。請記住,這可能會增加索引延遲。此外,您可能需要額外的 Amazon EBS 儲存以容納您要新增的複本。這將增加您的 EBS 磁碟區成本。
  • 請盡可能減少搜尋欄位、避免指令碼和萬用字元查詢。如需詳細資訊,請參閱 Elasticsearch 網站上的搜尋速度調整
  • 對於具有許多碎片的索引,您可以使用自訂路由來幫助加快搜尋速度。自訂路由確保只查詢保存資料的碎片,而不是將請求廣播到索引的所有碎片。如需詳細資訊,請參閱 Elasticsearch 網站上的 自訂您的文件路由

此文章是否有幫助?


您是否需要帳單或技術支援?