如何對 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. 對包含高度唯一值的欄位執行彙總，可能會導致堆積用量增加。如果彙總查詢已在使用中，則搜尋操作會使用 fielddata。Fielddata 也會排序和存取指令碼中的欄位值。Fielddata 移出取決於 indices.fielddata.cache.size 檔案的大小，這佔了 20％的 JVM 堆積空間。超過快取時，移出就會開始。

若要檢視 fielddata 快取，請使用以下請求：

GET /_nodes/stats/indices/fielddata?human

如需有關對高 JVM 記憶體進行疑難排解的詳細資訊，請參閱如何對 Amazon OpenSearch Service 叢集上的高 JVM 記憶體壓力進行疑難排解？
若要對高 CPU 使用率進行疑難排解，請參閱如何對 Amazon OpenSearch Service 叢集上的高 CPU 使用率進行疑難排解？

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

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

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

若要識別長時間執行的查詢，以及查詢花在特定碎片上的時間，請使用慢速日誌。您可以設定查詢階段的閾值，然後擷取每個索引的階段。如需有關設定慢速日誌的詳細資訊，請參閱檢視 Amazon Elasticsearch Service 慢速日誌。如需查詢在查詢階段所花費的時間的詳細明細，請為搜尋查詢設定 "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 節點之間的效能。
即使叢集處於非作用中狀態，具有太多碎片的叢集也可能會增加資源使用率。太多碎片會降低查詢效能。雖然增加複本碎片計數可以協助您達成更快的搜尋速度，但是在給定的節點上不要超過 1,000 個碎片。此外，請確保碎片大小介於 10 GiB 和 50 GiB 之間。理想情況下，節點上的碎片數目上限為堆積 \ * 20。
區段過多或已刪除文件過多可能會影響搜尋效能。若要改善執行效能，請在唯讀索引上使用強制合併。此外，如果可能的話，請增加作用中索引上的重新整理內部。如需詳細資訊，請參閱 Elastic 網站上的 Lucene 刪除文件處理。
如果您的叢集位於虛擬私有雲端 (VPC) 中，則最佳實務是在相同 VPC 中執行應用程式。
對唯讀資料，使用 UltraWarm 節點或熱資料節點。熱儲存可為索引和搜尋新資料提供最快的效能。不過，具成本效益的作法是使用 UltraWarm 節點在叢集上儲存大量唯讀資料。對於您不需要寫入且不需要高效能的索引，UltraWarm 可大幅降低每 GiB 資料的成本。
判斷您的工作負載是否因您搜尋的資料可在所有節點上使用而受益。部分應用程式會因這種方法而受益，特別是當叢集上的索引很少時。為些，請增加複本碎片的數量。
**注意：**這可能會增加索引的延遲。此外，您可能需要額外的 Amazon EBS 儲存空間來容納您新增的複本。這會增加您的 EBS 磁碟區成本。
搜尋盡可能少的欄位，並避免使用指令碼和萬用字元查詢。如需詳細資訊，請參閱 Elastic 網站上的](https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html)調校搜尋速度[。
對於具有許多碎片的索引，使用自訂路由有助於加快搜尋速度。自訂路由可確保您僅查詢保存資料的碎片，而不是將請求傳播給所有碎片。如需詳細資訊，請參閱 Elastic 網站上的自訂文件路由。