排解延遲問題

與任何資料庫系統一樣，Bigtable 也可能發生延遲問題。本文將探討 Bigtable 中延遲問題的常見原因，並說明如何排解這類問題。

請按照下列各節的疑難排解步驟，診斷及解決 Bigtable 延遲問題：

瞭解延遲時間過長的原因

下列因素會導致 Bigtable 發生延遲問題：

  • 伺服器延遲。系統會從 Bigtable 接收要求時開始計算伺服器延遲時間，並於 Bigtable 將資料的最後一個位元組傳送至用戶端時停止計算。對於資料量較大的要求，用戶端能否存取回應可能會影響伺服器延遲時間。
  • 作業延遲時間會測量 Bigtable 作業的端對端總時間，包括所有重試情況。這項指標會追蹤從用戶端到 Bigtable 再回到用戶端的往返時間。應用程式延遲、網路連線、Bigtable 用戶端程式庫延遲和伺服器延遲都會影響作業延遲。
  • 工作負載和要求模式可能會導致延遲時間增加，不僅是因為基礎架構問題，也可能是應用程式要求的工作模式發生變化。舉例來說，動態產生的掃描查詢先前掃描了一百列，但由於最近匯入資料或應用程式邏輯變更，現在掃描了一百萬列。雖然系統可能運作有效率，但單一作業的工作量大幅增加，導致執行時間變長，Bigtable 會將此視為延遲時間變長。

事前準備

如要排解高延遲問題，請執行下列工作：

  • 為用戶端程式庫啟用用戶端指標，以提升效能並解決問題。
  • 為縮短網路延遲時間，請確認應用程式與 Bigtable 叢集位於相同的區域。這可縮短應用程式與叢集之間的網路距離，進而縮短要求的回應時間。
  • 收集 Bigtable 環境的下列資訊：
  • 收集下列用戶端環境資訊：
  • 收集下列與問題相關的資訊：

排解延遲問題

如果 Bigtable 發生延遲問題，請按照下列步驟排解問題：

  1. 檢查伺服器延遲時間：在Google Cloud 控制台中使用「監控」頁面查看伺服器延遲時間。詳情請參閱「使用 Cloud Monitoring 進行監控」。檢查執行個體的延遲時間。如果執行個體包含多個叢集，請依叢集分割指標。如果發現讀取或寫入延遲圖表，或用戶端指標的延遲時間增加，請按照本文「排解伺服器延遲問題」一節中的伺服器延遲疑難排解步驟操作。
  2. 檢查用戶端延遲時間：啟用用戶端指標後，在 Cloud Monitoring Metrics Explorer 中搜尋 bigtable.googleapis.com/client。查看可用的用戶端指標。如果用戶端指標的延遲時間增加，但伺服器端指標沒有變化，請檢查應用程式和網路連線。詳情請參閱本文的「排解用戶端延遲問題」一節。

下圖顯示排解 Bigtable 延遲時間增加問題的程序：

Bigtable 延遲問題的疑難排解流程圖。
圖 1. 排解 Bigtable 延遲問題的程序 (按一下可放大)。

排解用戶端延遲問題

請按照下列步驟排解用戶端延遲問題。

事前準備

開始排解用戶端延遲問題前，請先完成下列工作：

  • 在 Bigtable 中啟用用戶端指標。
  • 如果您使用 Java 用戶端 2.17.1 以下版本，請啟用通道預先啟動。 從 2.18.0 版開始，頻道重新整理功能預設為啟用。
  • 反覆運算，找出工作負載的最佳連線集區大小。 如果管道不足或過多，可能會導致嘗試延遲時間過長。

檢查應用程式封鎖延遲時間

在 Google Cloud 控制台中檢查 Application Blocking Latencies 指標，然後執行下列任一動作：

  • 如果應用程式阻斷延遲時間偏高，且與回報的延遲時間增加相符，請著重於排解用戶端問題。
  • 如果應用程式封鎖延遲時間較長，且用戶端託管於Google Cloud 基礎架構 (例如 GKE 或 Compute Engine)，請向適當的 Google Cloud 支援團隊提報問題。
  • 如果應用程式封鎖延遲時間和 Bigtable 服務延遲時間都很短，延遲瓶頸可能位於網路或流量路徑的中間元件，例如網路或 Google 前端。建議將問題提交給網路團隊，請他們協助您完整擷取封包，找出延遲瓶頸。 Google Cloud

解決作業延遲時間過長的問題

  1. 如果 connectivity_error_count 偏高，表示應用程式無法順利連線至 Google 前端。設定較低的 RPC 超時，以便在不同管道上重試要求。
    • 如果 RPC 逾時時間過短，也可能導致作業延遲時間過長。判斷正常運作期間的典型 P99 RPC 逾時。將 RPC 超時值設為接近這個基準，有助於提升效能。
  2. 如果 retry_count 偏高，請檢查 attempt_latencies 狀態標記。如果嘗試失敗並出現 DEADLINE_EXCEEDED 錯誤，表示與平均 attempt_latencies 相比，要求截止時間太短。

在 gRPC 執行緒中排入佇列的位址要求

如果沒有任何指標超出常態，要求可能會在 gRPC 執行緒中排隊。可能原因如下：

  • 管道集區大小過小，要求會在 gRPC 管道中排隊。 詳情請參閱「緩衝要求」。
  • 用戶端 VM 的 CPU 使用率偏高。CPU 使用率過高也會導致用戶端要求排隊。

排解伺服器延遲問題

請按照下列步驟排解伺服器端延遲問題。

判斷叢集是否超載

  1. 查看 Read requests 和 Write requests 圖表，瞭解每秒查詢次數的變化。
  2. 查看 Node count 圖表，瞭解節點計數的變化。
  3. 檢查 Read throughput 和 Write throughput 圖表，確認頻寬是否增加。詳情請參閱「瞭解成效」。
  4. 如要瞭解應用程式設定檔、方法和資料表如何使用 CPU，以便排解效能問題，請參閱「Where is your Cloud Bigtable cluster spending its CPU?」網誌文章。
  5. 增加受影響叢集中的節點數量。詳情請參閱手動新增或移除節點和自動調度資源。確認平均 CPU 使用率維持在建議門檻以下。

檢查熱點

如果平板電腦使用的節點 CPU 百分比，與該節點相關聯的其他平板電腦相比，不成比例地高，如果對某個資料列範圍的要求量出乎意料地高，或是結構定義設計有瑕疵，就可能發生這種不平衡的用量情況。節點使用率不平衡可能會導致延遲時間變長和複寫延遲，也就是所謂的「熱點」。

  1. 觀察圖表中的熱點。CPU utilization (hottest node) high granularity
  2. 如要找出資源使用率不均的子表，請使用資源使用率不均的子表或 Key Visualizer 工具。
  3. 與叢集層級的 CPU 過度使用不同，您通常可以透過新增節點 (水平擴展) 解決 CPU 過度使用的問題，但熱點可能需要其他解決方法。這些技術包括變更建構資料列鍵的方式，或變更結構定義。詳情請參閱「在 Cloud Bigtable 中消除熱點」網誌文章。

解決 QPS 偏低時的延遲問題

Bigtable 最適合用於經常存取的大型資料表。如果您在一段時間未使用後傳送要求，Bigtable 重新建立連線時可能會出現高延遲現象。

  1. 如果 Read requests 和 Write requests 圖表顯示 QPS 偏低，回應時間可能會較長。
  2. 請按照「冷啟動和低 QPS」中的最佳做法，減輕冷啟動問題。

評估要求效率

使用查詢統計資料評估要求效率。查詢統計資料會顯示所見列數與傳回列數的比率，以及所見儲存格與傳回儲存格的比率，藉此指出查詢效率。重新檢視查詢模式或結構定義設計，提高要求效率。詳情請參閱「取得查詢統計資料」。

查看設定或應用程式設定檔變更

如果節點數量和輸送量維持不變，但平均 CPU 使用率增加，可能是因為複製或垃圾收集策略有所變更。詳情請參閱「複製與效能」。還原複製或垃圾收集的任何設定變更。

提報給 Bigtable 支援團隊

如果上述步驟無法解決問題，請將案件提報給 Bigtable 支援團隊。

後續步驟