如何疑難排解使用 ElastiCache for Redis 時的高延遲問題？

2 分的閱讀內容

如何疑難排解使用 Amazon ElastiCache for Redis 時的高延遲問題？

簡短描述

以下是 ElastiCache for Redis 中出現延遲升高或逾時問題的常見原因：

緩慢的命令造成的延遲。
高記憶體使用率導致交換增加。
網路問題造成的延遲。
用戶端延遲問題。
ElastiCache 叢集事件。

解析度

緩慢的命令造成的延遲

Redis 大多是單一執行緒。因此，當請求服務緩慢時，所有其他客戶都必須等待才能獲得服務。這種等待會增加命令延遲。Redis 命令也具有使用 Big O 標記法定義的時間複雜性。

使用由 ElastiCache 提供的Amazon CloudWatch 指標來監控不同類別命令的平均延遲。請注意，常見的 Redis 操作以微秒延遲計算。CloudWatch 指標每 1 分鐘進行一次抽樣，延遲指標會顯示多個命令的彙總。因此，單一命令可能會導致逾時等非預期結果，而不會在指標圖表中顯示重大變更。在這些情況下，請使用 SLOWLOG 命令來協助判斷哪些命令需要更長的時間才能完成。連線至叢集，並在 redis-cli 中執行 slowlog get 128 命令以擷取清單。如需詳細資料，請參閱如何在 ElastiCache for Redis 快取叢集中開啟 Redis 慢速日誌？

您也可能會看到 CloudWatch 中的 EngineCPUUtilization 指標有所增加，這是因為緩慢的命令會封鎖 Redis 引擎。如需詳細資訊，請參閱為什麼我在 ElastiCache for Redis 叢集中看到 CPU 用量很高或不斷增加？

複雜命令的範例包含：

大型資料集上生產環境中的 KEYS，因為其會掃描整個金鑰空間，搜尋指定的模式。
長時間執行的 LUA 指令碼。

高記憶體使用率導致更高的交換

當叢集上的記憶體壓力增加時，Redis 會開始使用多於可用量的記憶體來交換頁面。當記憶體頁面傳入交換區域，或從交換區域傳輸時，延遲和逾時問題會增加。以下是 CloudWatch 指標中增加交換的指標：

SwapUsage 增加。
非常低的 FreeableMemory。
高 BytesUsedForCache 和 DatabaseMemoryUsagePercentage 指標。

SwapUsage 是一個主機級指標，用於指示要交換的記憶體量。此指標顯示非零值是正常的，因為該指標是由基礎作業系統控制，可能受到許多動態因素影響。這些因素包括作業系統版本、活動模式等。Linux 主動將用戶端很少存取的閒置金鑰交換到磁碟，以作為一種最佳化技術，釋放記憶體空間供更常用的金鑰使用。

當沒有足夠的可用記憶體時，交換成為一個問題。發生這種情況時，系統會開始在磁碟和記憶體之間來回移動頁面。具體來說，SwapUsage 少於幾百 MB 不會對 Redis 的效能產生負面影響。如果 SwapUsage 高且主動變更，而且叢集上沒有足夠的記憶體可用，則會影響效能。如需詳細資訊，請參閱：

網路造成的延遲

用戶端與 ElastiCache 叢集之間的網路延遲

若要隔離用戶端和叢集節點之間的網路延遲，請使用應用程式環境中的 TCP tracerout 或 mtr 測試。或者，請使用偵錯工具，例如 AWSSupport-SetupIPMonitoringFromVPC AWS Systems Manager 文件 (SSM 文件)，測試來自用戶端子網路的連線。

叢集達到網路限制

ElastiCache 節點與對應的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體類型共用相同的網路限制。例如，cache.m6g.large 的節點類型與 m6g.large EC2 執行個體有相同的網路限制。如需詳細了解檢查頻寬功能、每秒封包 (PPS) 效能和追蹤連線的三個關鍵網路效能元件，請參閱監控 EC2 執行個體的網路效能。

若要疑難排解 ElastiCache 節點上的網路限制問題，請參閱疑難排解 - 網路相關限制。

TCP/SSL 交握延遲

客戶端使用 TCP 連接連接到 Redis 叢集。建立 TCP 連線需要幾毫秒。額外的毫秒會在應用程式執行的 Redis 作業上建立額外負荷，並在 Redis CPU 上產生額外壓力。考量到 TLS 交握所需的額外時間和 CPU 使用率，當叢集使用 ElastiCache 傳輸中加密功能時，請務必控制新連線的數量。快速開啟和關閉的大量連線 (NewConnections) 可能影響節點效能。您可以使用連線共用將已建立的 TCP 連線快取至集區。然後，每當新的用戶端嘗試連線到叢集時，就會重複使用這些連線。您可以使用 Redis 客戶端庫 (若支援) 實作連線共用，並使用適用於應用程式環境的框架，或從頭開始構建。您也可以使用 MSET/MGET 等彙總命令作為最佳化技術。

ElastiCache 節點上有大量的連線

這是追蹤 CurrConnections 和 NewConnections CloudWatch 指標的最佳實務。這些指標會監控 Redis 接受的 TCP 連線數量。大量的 TCP 連線可能會導致 65,000 個 maxclients 限制耗盡。此限制是每個節點可以擁有的最大並行連線數量。如果您達到 65,000 上限，您會收到用戶端達到的 ERR 最大數量錯誤。如果新增更多連線，超出 Linux 伺服器限制，或超出追蹤的連線數量上限，額外的用戶端連線會導致連線逾時錯誤。如需詳細了解防止大量連線，請參閱最佳實務：Redis 用戶端和 Amazon ElastiCache for Redis。

客戶端延遲問題

延遲和逾時可能源自用戶端本身。驗證用戶端的記憶體、CPU 和網路使用率，以判斷這些資源是否達到限制。如果應用程式在 EC2 執行個體上執行，請利用先前所述的相同 CloudWatch 指標來檢查問題。延遲可能發生在預設 CloudWatch 指標無法完全監控的作業系統中。請考慮在 EC2 執行個體內安裝監控工具，例如 atop 或 CloudWatch 代理程式。

如果在應用程式端設定的逾時組態值太小，您可能會收到不必要的逾時錯誤。適當地設定用戶端逾時，讓伺服器有足夠時間處理要求並產生回應。請參閱最佳實務：Redis 用戶端和 Amazon ElastiCache for Redis。

從您的應用程式收到的逾時錯誤會顯示其他詳細資料。這些詳細資料包括是否涉及特定節點、導致逾時的 Redis 資料類型名稱、逾時發生時間的確切時間戳記等等。此資訊可協助您找出問題模式。使用此資訊回答以下問題：

逾時是否經常在一天中的特定時間發生？
逾時是否發生在一個用戶端或多個用戶端？
逾時是否發生在一個 Redis 節點或多個節點？
逾時是否發生在一個或多個叢集上？

使用這些模式來調查最有可能的用戶端或 ElastiCache 節點。您也可以使用應用程式日誌和 VPC 流程日誌來判斷延遲是否發生在用戶端、ElastiCache 節點或網路上。

Redis 的同步

Redis 的同步會在備份、取代和擴展事件期間啟動。這是運算密集型工作負載，可能會造成延遲。請使用 SaveInProgress CloudWatch 指標來判斷同步是否正在進行中。如需詳細資訊，請參閱如何實作同步和備份。

ElastiCache 叢集事件

請檢查 ElastiCache 主控台的事件部分，了解有延遲的時間區段。請檢查是否可能由 ElastiCache 管理維護和服務更新所造成的背景活動，例如節點取代或容錯移轉事件，或是否有未預期的硬體故障。您會透過 PHD 儀表板和電子郵件收到排程活動的通知。

以下是範例事件日誌：

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed