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

上次更新日期:2022 年 8 月 4 日

如何疑難排解使用 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
  • BytesUsedForCacheDatabaseMemoryUsagePercentage 指標。

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 節點上有大量的連線

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

客戶端延遲問題

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

如果在應用程式端設定的逾時組態值太小,您可能會收到不必要的逾時錯誤。適當地設定用戶端逾時,讓伺服器有足夠時間處理要求並產生回應。請參閱最佳實務: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