交易統計資料

Spanner 提供內建資料表，用於儲存交易相關統計資料。您可以使用 SQL 陳述式從這些 SPANNER_SYS.TXN_STATS* 資料表擷取統計資料。

使用交易統計資料的時機

交易統計資料可用於調查效能問題。舉例來說，您可以檢查是否有任何執行速度緩慢的交易，可能會影響資料庫中的效能或每秒查詢次數 (QPS)。另一種情況是，您的用戶端應用程式發生高交易執行延遲情形。分析交易統計資料有助於發現可能影響延遲時間的潛在瓶頸，例如特定資料欄的大量更新。

可用性

SPANNER_SYS 資料只能透過 SQL 介面取得，例如：

• Google Cloud 控制台中資料庫的 Spanner Studio 頁面

• gcloud spanner databases execute-sql 指令

• 「交易深入分析」資訊主頁

• executeQuery API

Spanner 提供的其他單一讀取方法不支援 SPANNER_SYS。

按交易分組的延遲時間統計資料

下表會追蹤特定時間範圍內 TOP 資源消耗交易的統計資料。

• SPANNER_SYS.TXN_STATS_TOP_MINUTE：匯總 1 分鐘間隔內的交易統計資料。

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE：每 10 分鐘間隔匯總的交易統計資料。

• SPANNER_SYS.TXN_STATS_TOP_HOUR：每 1 小時間隔匯總的交易統計資料。

這些資料表具備下列屬性：

• 每個資料表都包含資料表名稱所指定的非重疊時間間隔長度的資料。

• 間隔是基於時鐘時間。1 分鐘間隔的結束時間是目前這一分鐘、10 分鐘間隔的結束時間是目前這個小時的每 10 分鐘，而 1 小時間隔的結束時間是目前這個小時。

  舉例來說，在上午 11:59:30，SQL 查詢的最近可用間隔如下：

  • 1 分鐘：上午 11:58:00–11:58:59
  • 10 分鐘：上午 11:40:00–11:49:59
  • 1 小時：上午 10:00:00–10:59:59

• Spanner 會依據交易的 FPRINT (指紋) 將統計資料分組。如果有交易標記，FPRINT 就是標記的雜湊值。否則，雜湊是根據交易涉及的作業計算得出。

• 統計資料是根據 FPRINT 分組，因此如果在任何時間間隔內執行相同交易多次，這些表格中仍只會顯示該交易的一個項目。

• 每個資料列都包含 Spanner 在指定間隔期間擷取特定交易的統計資料，這些資料是針對該交易的所有執行作業擷取。

• 如果 Spanner 無法在這些表格中儲存間隔期間執行的所有交易統計資料，系統會優先處理在指定間隔期間延遲時間、提交嘗試次數和寫入位元組最高的交易。

• 資料表中的所有欄均可為空值。

資料表結構定義

¹ _exists 是用於檢查特定資料列是否存在的內部欄位。

查詢範例

本節包含多個擷取交易統計資料的範例 SQL 陳述式。您可以使用用戶端程式庫、gcloud spanner 或 Google Cloud 主控台執行這些 SQL 陳述式。

列出特定時間範圍內每筆交易的基本統計資料

下列查詢會傳回前一分鐘中，前幾筆交易的原始資料。

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       operations_by_table,
       avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_minute);

查詢輸出

列出平均提交延遲時間最長的交易

下列查詢會傳回前一小時中平均提交延遲時間較高的交易，並依平均提交延遲時間由高至低排序。

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds,
       avg_commit_latency_seconds,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;

查詢輸出

找出讀取特定欄位的交易平均延遲時間

下列查詢會傳回交易的平均延遲時間資訊，這些交易會從 1 小時的統計資料中讀取 ADDRESS 欄：

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;

查詢輸出

依據平均修改位元組數列出交易

下列查詢會傳回過去一小時內取樣的交易，並依據交易修改的平均位元組數排序。

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;

查詢輸出

匯總統計資料

SPANNER_SYS 也包含資料表，可儲存 Spanner 在特定時間範圍內擷取所有交易的匯總資料：

• SPANNER_SYS.TXN_STATS_TOTAL_MINUTE：1 分鐘間隔期間內所有交易的匯總統計資料
• SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE：10 分鐘間隔期間內所有交易的匯總統計資料
• SPANNER_SYS.TXN_STATS_TOTAL_HOUR：1 小時間隔期間內所有交易的匯總統計資料

匯總統計資料表格具有下列屬性：

• 每個資料表都包含資料表名稱所指定的非重疊時間間隔長度的資料。

• 間隔是基於時鐘時間。1 分鐘間隔的結束時間是目前這一分鐘、10 分鐘間隔的結束時間是目前這個小時的每 10 分鐘，而 1 小時間隔的結束時間是目前這個小時。

  舉例來說，在上午 11:59:30，SQL 查詢的最近可用間隔如下：

  • 1 分鐘：上午 11:58:00–11:58:59
  • 10 分鐘：上午 11:40:00–11:49:59
  • 1 小時：上午 10:00:00–10:59:59

• 每個資料列都會包含指定間隔期間，資料庫上執行的所有交易的統計資料匯總。每個時間間隔只有一個資料列。

• SPANNER_SYS.TXN_STATS_TOTAL_* 資料表中擷取的統計資料可能包含 Spanner 未在 SPANNER_SYS.TXN_STATS_TOP_* 資料表中擷取的交易。

• 這些資料表中的部分欄會在 Cloud Monitoring 中顯示為指標。公開的指標如下：

  • 提交嘗試次數
  • 提交重試次數
  • 交易參與者
  • 交易延遲時間
  • 寫入的位元組

  詳情請參閱「Spanner 指標」。

資料表結構定義

查詢範例

本節包含多個擷取交易統計資料的範例 SQL 陳述式。您可以使用用戶端程式庫、gcloud spanner 或 Google Cloud 主控台執行這些 SQL 陳述式。

找出所有交易的總提交嘗試次數

下列查詢會傳回最近完成的 1 分間隔內，所有交易的提交嘗試次數總數：

SELECT interval_end,
       commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;

查詢輸出

請注意，結果中只有一個資料列，因為匯總統計資料在任何時間範圍內，每個 interval_end 只有一個項目。

找出所有交易的總提交延遲時間

下列查詢會傳回過去 10 分鐘內所有交易的總提交延遲時間：

SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
  AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute);

查詢輸出

請注意，結果中只有一個資料列，因為匯總統計資料在任何時間範圍內，每個 interval_end 只有一個項目。

找出交易的第 99 個百分位數延遲時間

下列查詢會傳回過去 10 分鐘內執行的交易第 99 個百分位數延遲時間：

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;

查詢輸出

請注意，平均延遲時間與第 99 百分位延遲時間之間的差異很大。第 99 個百分位數的延遲時間有助於找出可能的異常交易，這些交易的延遲時間較長。

結果中只有一列，因為匯總統計資料在任何時間範圍內，每個 interval_end 只有一筆項目。

資料保留

Spanner 至少會在下列時間範圍保留每個資料表的資料：

• SPANNER_SYS.TXN_STATS_TOP_MINUTE 和 SPANNER_SYS.TXN_STATS_TOTAL_MINUTE：涵蓋前 6 個小時的間隔。

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE 和 SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE：涵蓋前 4 天的間隔。

• SPANNER_SYS.TXN_STATS_TOP_HOUR 和 SPANNER_SYS.TXN_STATS_TOTAL_HOUR：涵蓋前 30 天的間隔。

Spanner 中的交易統計資料可讓您深入瞭解應用程式如何使用資料庫，並在調查效能問題時提供實用資訊。舉例來說，您可以檢查是否有任何執行速度緩慢的交易可能導致爭用情形，或是找出可能造成高負載的潛在來源，例如對特定資料欄進行大量更新。我們將透過以下步驟，說明如何使用交易統計資料，調查資料庫中的競爭行為。

瞭解交易和提交次數

Spanner 交易可能會在修訂之前進行多次嘗試。這種情況最常發生在兩個交易嘗試同時處理相同資料，且其中一個交易需要中止，以保留交易的隔離屬性時。其他可能導致交易中止的暫時性事件包括：

• 網路發生暫時性問題。

• 在交易提交期間，套用資料庫結構定義變更。

• Spanner 執行個體無法處理收到的所有要求。

在這種情況下，用戶端應重試已中止的交易，直到交易成功提交或逾時為止。對於官方 Spanner 用戶端程式庫的使用者，每個程式庫都已實作自動重試機制。如果您使用的是自訂版本的用戶端程式碼，請在重試迴圈中包裝交易提交作業。

由於無法復原的錯誤 (例如交易逾時、權限問題或無效的資料表/欄名稱)，Spanner 交易也可能會中止。這類交易不需要重試，Spanner 用戶端程式庫會立即傳回錯誤。

下表列出 COMMIT_ATTEMPT_COUNT、COMMIT_ABORT_COUNT 和 COMMIT_RETRY_COUNT 在不同情境下記錄的範例。

交易統計資料表中的資料是一段時間內的匯總資料。在特定間隔內，交易可能會在邊界附近中止及重試，並落入不同的分層。因此，在特定時間間隔內，中斷和重試的次數可能不相等。

這些統計資料旨在協助排解問題和進行內省，但不保證 100% 準確。統計資料會先在記憶體中匯總，再儲存在 Spanner 資料表中。在升級或其他維護作業期間，Spanner 伺服器可能會重新啟動，進而影響數字的準確性。

使用交易統計資料排解資料庫爭用問題

您可以使用 SQL 程式碼或「交易深入分析」資訊主頁，查看資料庫中可能因鎖定爭用而造成高延遲的交易。

下列主題說明如何使用 SQL 程式碼調查這類交易。

選取要調查的時間範圍

這項資訊可在使用 Spanner 的應用程式中找到。

在本練習中，假設問題是在 2020 年 5 月 17 日下午 5 點 20 分左右開始發生。

您可以使用交易標記來找出交易來源，並將交易統計資料表和鎖定統計資料表進行關聯，以便有效排解鎖定爭用問題。詳情請參閱交易標記疑難排解。

收集所選時間範圍內的交易統計資料

為了展開調查，我們會查詢問題開始時的 TXN_STATS_TOTAL_10MINUTE 資料表。這項查詢的結果會顯示延遲和其他交易統計資料在該期間的變化情形。

舉例來說，下列查詢會傳回從 4:30 pm 到 7:40 pm (含) 的匯總交易統計資料。

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  commit_attempt_count,
  commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;

下表列出查詢傳回的資料範例。

這裡顯示，在已醒目顯示的期間，匯總的延遲時間和中止次數較高。我們可以選擇任何 10 分鐘的間隔，其中的總延遲時間和/或中止計數較高。請選擇結束於 2020-05-17T18:40:00 的間隔，並在下一個步驟中使用該間隔，找出造成高延遲和中止計數的交易。

找出延遲時間偏高的交易

接下來，我們將針對先前步驟中選取的時間間隔，查詢 TXN_STATS_TOP_10MINUTE 資料表。我們可以利用這些資料，找出哪些交易的延遲時間和/或中止次數偏高。

執行下列查詢，針對結束於 2020-05-17T18:40:00 的範例間隔，依總延遲時間由高至低的順序取得影響效能表現的交易。

SELECT
  interval_end,
  fprint,
  ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
  ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;

我們可以清楚看到，上表第一列 (已醒目顯示) 顯示的交易因提交中止次數過多而發生高延遲。我們也發現重試次數過多，這表示系統後續會重試已中止的修訂版本。在下一個步驟中，我們會進一步調查導致這個問題的原因。

找出交易中延遲時間較長的資料欄

在這個步驟中，我們會檢查是否有高延遲交易在相同的資料欄上運作，方法是擷取交易的 read_columns、write_constructive_columns 和 write_delete_tables 資料，並計算中止次數。FPRINT 值也會在下一個步驟中派上用場。

SELECT
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;

如上表的輸出結果所示，平均總延遲時間最高的交易會讀取相同的資料欄。我們也可以觀察到一些寫入競爭，因為交易會寫入相同的資料欄，也就是 TestHigherLatency._exists。

判斷交易成效的長期變化

我們可以查看與此交易形狀相關聯的統計資料，在一段時間內的變化情形。請使用下列查詢，其中 $FPRINT 是上一個步驟中高延遲交易的指紋。

SELECT
  interval_end,
  ROUND(avg_total_latency_seconds, 3) AS latency,
  ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count,
  commit_failed_precondition_count,
  avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  interval_end >= "2020-05-17T16:40:00"
  AND interval_end <= "2020-05-17T19:40:00"
  AND fprint = $FPRINT
ORDER BY interval_end;

在上述輸出結果中，我們可以觀察到在醒目顯示的時間範圍內，總延遲時間偏高。而且，無論總延遲時間有多高，commit_attempt_count、commit_abort_count 和 commit_retry_count 也都會很高，即使提交延遲時間 (commit_latency) 並未大幅變動也是如此。由於交易提交作業會更頻繁地中止，因此提交重試也會導致提交嘗試次數增加。

結論

在這個範例中，我們發現高提交中止計數是造成高延遲的原因。下一個步驟是查看應用程式收到的提交中止錯誤訊息，瞭解中止的原因。檢查應用程式中的記錄後，我們發現應用程式在此期間確實變更了工作負載，也就是說，其他交易形狀顯示出高 attempts_per_second，而其他交易 (可能是每晚的清理工作) 導致其他鎖定衝突。

找出未正確重試的交易

下列查詢會傳回過去十分鐘內取樣的交易，這些交易的提交中止次數偏高，但沒有重試。

SELECT
  *
FROM (
  SELECT
    fprint,
    SUM(commit_attempt_count) AS total_commit_attempt_count,
    SUM(commit_abort_count) AS total_commit_abort_count,
    SUM(commit_retry_count) AS total_commit_retry_count
  FROM
    SPANNER_SYS.TXN_STATS_TOP_10MINUTE
  GROUP BY
    fprint )
WHERE
  total_commit_retry_count = 0
  AND total_commit_abort_count > 0
ORDER BY
  total_commit_abort_count DESC;

我們發現，使用 fprint 1557557373282541312 的交易已中止 44232 次，但從未重試。這看起來很可疑，因為中止計數很高，而且每個中止都不可能是由無法重試的錯誤造成。另一方面，如果交易的 fprint 為 5776062322886969344，則不太可疑，因為總中止次數不高。

以下查詢會傳回 fprint 交易的更多詳細資料 (1557557373282541312)，包括 read_columns、write_constructive_columns 和 write_delete_tables。這項資訊有助於在用戶端程式碼中找出交易，方便您針對此情況查看重試邏輯。

SELECT
  interval_end,
  fprint,
  read_columns,
  write_constructive_columns,
  write_delete_tables,
  commit_attempt_count,
  commit_abort_count,
  commit_retry_count
FROM
  SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
  fprint = 1557557373282541312
ORDER BY
  interval_end DESC;

我們可以看到，交易涉及讀取 Singers._exists 隱藏欄，以便檢查資料列是否存在。交易也會寫入 Singers.FirstName 和 Singer.LastName 欄。這項資訊有助於判斷自訂用戶端程式庫中實作的交易重試機制是否正常運作。

後續步驟

• 瞭解其他內省工具。
• 瞭解 Spanner 為每個資料庫儲存的其他資訊。這些資訊儲存在資料庫的資訊結構定義資料表中。
• 進一步瞭解 Spanner 的 SQL 最佳做法。
• 進一步瞭解如何調查 CPU 使用率偏高的問題。