Statistik transaksi

Dokumen ini menjelaskan statistik transaksi yang ditawarkan Spanner sebagai tabel bawaan. Anda dapat mengambil statistik dari tabel SPANNER_SYS.TXN_STATS* ini menggunakan pernyataan SQL.

Kapan harus menggunakan statistik transaksi

Statistik transaksi berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa apakah ada transaksi yang berjalan lambat yang mungkin memengaruhi performa atau Kueri Per Detik (QPS) di database Anda. Skenario lainnya adalah saat aplikasi klien Anda mengalami latensi eksekusi transaksi yang tinggi. Menganalisis statistik transaksi dapat membantu menemukan potensi bottleneck, seperti volume update yang besar pada kolom tertentu, yang mungkin memengaruhi latensi.

Cara mengakses statistik transaksi

Spanner menyediakan statistik transaksi tabel dalam skema SPANNER_SYS. Anda dapat menggunakan cara berikut untuk mengakses data SPANNER_SYS:

Metode baca tunggal berikut yang disediakan Spanner tidak mendukung SPANNER_SYS:

  • Melakukan pembacaan kuat dari satu baris atau beberapa baris dalam tabel.
  • Melakukan pembacaan usang dari satu baris atau beberapa baris dalam tabel.
  • Membaca dari satu baris atau beberapa baris dalam indeks sekunder.

Statistik latensi yang dikelompokkan menurut transaksi

Tabel berikut melacak statistik untuk transaksi yang menggunakan resource TOP selama jangka waktu tertentu.

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE: statistik transaksi yang digabungkan dalam interval 1 menit.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE: statistik transaksi yang digabungkan dalam interval 10 menit.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR: statistik transaksi yang digabungkan dalam interval 1 jam.

Tabel ini memiliki properti berikut:

  • Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dari durasi yang ditentukan oleh nama tabel.

  • Interval didasarkan pada waktu jam

    • Interval 1 menit berakhir pada menit tersebut.
    • Interval 10 menit berakhir setiap 10 menit mulai dari jam.
    • Interval 1 jam berakhir pada jam tersebut.

    Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL adalah:

    • 1 menit: 11.58.00–11.58.59
    • Menit ke-10: 11.40.00–11.49.59
    • 1 jam: 10.00.00–10.59.59

  • Spanner mengelompokkan statistik berdasarkan FPRINT (Sidik Jari) transaksi. Jika tag transaksi ada, FPRINT adalah hash tag. Jika tidak, hash akan dihitung berdasarkan operasi yang terlibat dalam transaksi.

  • Karena statistik dikelompokkan berdasarkan FPRINT, jika transaksi yang sama dieksekusi beberapa kali dalam interval waktu tertentu, hanya satu entri yang muncul untuk transaksi tersebut dalam tabel ini.

  • Setiap baris berisi statistik untuk semua eksekusi transaksi tertentu yang statistiknya dicatat oleh Spanner selama interval yang ditentukan.

  • Jika Spanner tidak dapat menyimpan statistik untuk semua transaksi yang dijalankan selama interval dalam tabel ini, sistem akan memprioritaskan transaksi dengan latensi, upaya commit, dan byte tertinggi yang ditulis selama interval yang ditentukan.

  • Semua kolom dalam tabel dapat bernilai null.

Skema tabel

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu terjadinya eksekusi transaksi yang disertakan.
TRANSACTION_TAG STRING Tag transaksi opsional untuk operasi transaksi ini. Untuk informasi selengkapnya tentang cara menggunakan tag, lihat Memecahkan masalah dengan tag transaksi. Statistik untuk beberapa transaksi yang memiliki string tag yang sama dikelompokkan dalam satu baris dengan `TRANSACTION_TAG` yang cocok dengan string tag tersebut.
FPRINT INT64 Hash TRANSACTION_TAG jika ada; Jika tidak, hash dihitung berdasarkan operasi yang terlibat dalam transaksi. INTERVAL_END dan FPRINT bersama-sama bertindak sebagai kunci unik untuk tabel ini.
READ_COLUMNS ARRAY<STRING> Kumpulan kolom yang dibaca oleh transaksi.
WRITE_CONSTRUCTIVE_COLUMNS ARRAY<STRING> Kumpulan kolom yang ditulis secara konstruktif, yang ditetapkan ke nilai baru, oleh transaksi.

Untuk aliran data perubahan, jika transaksi melibatkan penulisan ke kolom dan tabel yang dipantau oleh aliran data perubahan, WRITE_CONSTRUCTIVE_COLUMNS berisi dua kolom - .data dan ._exists , diawali dengan nama aliran data perubahan. _exists adalah kolom yang digunakan untuk memeriksa apakah baris tertentu ada atau tidak.
WRITE_DELETE_TABLES ARRAY<STRING> Kumpulan tabel yang barisnya dihapus atau diganti oleh transaksi.
ATTEMPT_COUNT INT64 Total jumlah upaya transaksi, termasuk upaya yang dibatalkan sebelum memanggil metode commit. Jumlah ini menunjukkan total upaya selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_ATTEMPT_COUNT INT64 Jumlah total upaya commit transaksi. Jumlah ini harus cocok dengan jumlah panggilan ke metode commit transaksi. Jumlah ini menunjukkan total upaya commit selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_ABORT_COUNT INT64 Jumlah total upaya transaksi yang dibatalkan, termasuk upaya yang dibatalkan sebelum memanggil metode commit transaksi. Jumlah ini menunjukkan total pembatalan selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_RETRY_COUNT INT64 Jumlah total upaya yang merupakan percobaan ulang dari upaya yang dibatalkan sebelumnya. Transaksi Spanner mungkin dicoba beberapa kali sebelum di-commit karena pertentangan kunci atau peristiwa sementara. Jumlah percobaan ulang yang tinggi dibandingkan dengan upaya commit menunjukkan bahwa mungkin ada masalah yang perlu diselidiki. Untuk informasi selengkapnya, lihat Memahami transaksi dan jumlah commit di halaman ini.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Total jumlah upaya commit transaksi yang menampilkan error prasyarat gagal, seperti pelanggaran indeks UNIQUE, baris sudah ada, atau baris tidak ditemukan.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 Jumlah total upaya transaksi yang dimulai dengan tingkat isolasi SERIALIZABLE dan penguncian PESSIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
SERIALIZABLE_OPTIMISTIC_TXN_COUNT INT64 Jumlah total upaya transaksi yang dimulai dengan tingkat isolasi SERIALIZABLE dan penguncian OPTIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 Jumlah total upaya transaksi yang dimulai dengan tingkat isolasi REPEATABLE READ dan penguncian OPTIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 Jumlah rata-rata peserta dalam setiap upaya commit. Untuk mempelajari lebih lanjut peserta, lihat Proses Operasi Baca & Tulis Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Rata-rata detik yang diperlukan dari operasi pertama transaksi hingga commit/pembatalan.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Rata-rata detik yang diperlukan untuk melakukan operasi commit.
AVG_BYTES FLOAT64 Jumlah rata-rata byte yang ditulis oleh transaksi.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau pembatalan, untuk semua upaya transaksi.

Jika transaksi dibatalkan beberapa kali dan kemudian berhasil di-commit, latensi akan diukur untuk setiap upaya hingga commit terakhir berhasil. Nilai diukur dalam detik.

Array berisi satu elemen dan memiliki jenis berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Untuk mengetahui informasi selengkapnya tentang nilai, lihat Distribution dan Exponential.

Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi.

Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan dengan frekuensi baris terpengaruh dan jumlah byte yang ditulis.

Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

Tentukan array sebagai berikut:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau pembatalan, untuk semua upaya transaksi.

Representasi string yang kompatibel dengan JSON dari statistik TOTAL_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan dalam TOTAL_LATENCY_DISTRIBUTION.

Jika transaksi dibatalkan beberapa kali dan kemudian berhasil di-commit, latensi akan diukur untuk setiap upaya hingga commit terakhir berhasil. Nilai diukur dalam detik.

Kolom ini didukung dalam database dialek GoogleSQL dan dialek PostgreSQL. Kolom ini berisi Distribusi.

Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi menggunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.

OPERATIONS_BY_TABLE_JSON_STRING STRING

Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan dengan frekuensi baris terpengaruh dan jumlah byte yang ditulis.

Representasi string yang kompatibel dengan JSON dari kolom OPERATIONS_BY_TABLE. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom OPERATIONS_BY_TABLE.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogram jumlah detik yang diperlukan untuk melakukan operasi commit.

Array memiliki struktur berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Untuk mengetahui informasi selengkapnya tentang jenis nilai, lihat Distribusi dan Eksponensial.

Untuk menghitung persentil latensi commit dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

Representasi string yang kompatibel dengan JSON dari statistik COMMIT_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom COMMIT_LATENCY_DISTRIBUTION.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Untuk menghitung persentil latensi commit dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

Histogram jumlah peserta dalam setiap upaya commit.

Array memiliki struktur berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Untuk mengetahui informasi selengkapnya tentang jenis nilai, lihat Distribution dan Exponential.

Untuk menghitung persentil peserta dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

Representasi string yang kompatibel dengan JSON dari statistik PARTICIPANTS_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom PARTICIPANTS_DISTRIBUTION.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Untuk menghitung persentil peserta dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Contoh kueri

Bagian ini mencakup beberapa contoh pernyataan SQL yang mengambil statistik transaksi. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsolGoogle Cloud .

Mencantumkan statistik dasar untuk setiap transaksi dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah untuk transaksi teratas dalam menit sebelumnya.

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);
Output kueri
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds operations_by_table avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 [["Cars",1107,30996],["Routes",560,26880]] 25286
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 [] 0
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 [] 0

Mencantumkan transaksi dengan latensi commit rata-rata tertinggi

Kueri berikut menampilkan transaksi dengan latensi commit rata-rata yang tinggi pada jam sebelumnya, yang diurutkan dari latensi commit rata-rata tertinggi hingga terendah.

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;
Output kueri
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds avg_commit_latency_seconds avg_bytes
40015598317 [] ["Routes.name", "Cars.model"] ["Users"] 0.006578737 0.006547737 25286
77848338483 [] [] ["Cars", "Routes"] 0.033467418 0.000251418 0
20524969030 ["id", "no"] [] [] 0.001732442 0.000247442 0

Menemukan latensi rata-rata transaksi yang membaca kolom tertentu

Kueri berikut menampilkan informasi latensi rata-rata untuk transaksi yang membaca kolom ADDRESS dari statistik 1 jam:

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;
Output kueri
fprint read_columns write_constructive_columns write_delete_tables avg_total_latency_seconds
77848338483 ["ID", "ADDRESS"] [] ["Cars", "Routes"] 0.033467418
40015598317 ["ID", "NAME", "ADDRESS"] [] ["Users"] 0.006578737

Mencantumkan transaksi berdasarkan jumlah rata-rata byte yang diubah

Kueri berikut menampilkan transaksi yang dijadikan sampel dalam satu jam terakhir, yang diurutkan berdasarkan jumlah rata-rata byte yang diubah oleh transaksi.

SELECT fprint,
       read_columns,
       write_constructive_columns,
       write_delete_tables,
       avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;
Output kueri
fprint read_columns write_constructive_columns write_delete_tables avg_bytes
40015598317 [] [] ["Users"] 25286
77848338483 [] [] ["Cars", "Routes"] 12005
20524969030 ["ID", "ADDRESS"] [] ["Users"] 10923

Statistik gabungan

SPANNER_SYS juga berisi tabel untuk menyimpan data gabungan untuk semua transaksi yang statistiknya diambil oleh Spanner dalam jangka waktu tertentu:

  • SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Statistik gabungan untuk semua transaksi selama interval 1 menit
  • SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Statistik gabungan untuk semua transaksi selama interval 10 menit
  • SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Statistik gabungan untuk semua transaksi selama interval 1 jam

Tabel statistik gabungan memiliki properti berikut:

  • Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dengan durasi yang ditentukan oleh nama tabel.

  • Interval didasarkan pada waktu jam. Interval 1 menit berakhir pada menit, interval 10 menit berakhir setiap 10 menit mulai dari jam, dan interval 1 jam berakhir pada jam.

    Misalnya, pada pukul 11.59.30, interval terbaru yang tersedia untuk kueri SQL pada statistik transaksi gabungan adalah:

    • 1 menit: 11.58.00–11.58.59
    • Menit ke-10: 11.40.00–11.49.59
    • 1 jam: 10.00.00–10.59.59

  • Setiap baris berisi statistik untuk semua transaksi yang dijalankan di database selama interval yang ditentukan, yang digabungkan bersama. Hanya ada satu baris per interval waktu.

  • Statistik yang dicatat dalam tabel SPANNER_SYS.TXN_STATS_TOTAL_* mungkin mencakup transaksi yang tidak dicatat Spanner dalam tabel SPANNER_SYS.TXN_STATS_TOP_*.

  • Beberapa kolom dalam tabel ini ditampilkan sebagai metrik di Cloud Monitoring. Metrik yang ditampilkan adalah:

    • Jumlah upaya commit
    • Jumlah percobaan ulang commit
    • Peserta transaksi
    • Latensi transaksi
    • Byte yang ditulis

    Untuk mengetahui informasi selengkapnya, lihat Metrik Spanner.

Skema tabel

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu saat statistik ini diambil.
ATTEMPT_COUNT INT64 Jumlah total upaya transaksi, termasuk upaya yang dibatalkan sebelum memanggil `commit`. Jumlah ini menunjukkan total upaya selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_ATTEMPT_COUNT INT64 Jumlah total upaya commit transaksi. Jumlah ini harus cocok dengan jumlah panggilan ke metode commit transaksi. Jumlah ini menunjukkan total upaya commit selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_ABORT_COUNT INT64 Jumlah total upaya transaksi yang dibatalkan, termasuk upaya yang dibatalkan sebelum memanggil metode commit transaksi. Jumlah ini menunjukkan total pembatalan selama interval yang ditentukan. Untuk mengetahui informasi selengkapnya tentang interval, lihat Interval.
COMMIT_RETRY_COUNT INT64 Jumlah upaya commit yang merupakan percobaan ulang dari upaya yang dibatalkan sebelumnya. Transaksi Spanner mungkin telah dicoba beberapa kali sebelum di-commit karena pertentangan kunci atau peristiwa sementara. Jumlah percobaan ulang yang tinggi dibandingkan dengan upaya commit menunjukkan bahwa mungkin ada masalah yang perlu diselidiki. Untuk informasi selengkapnya, lihat Memahami transaksi dan jumlah commit di halaman ini.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Jumlah total upaya commit transaksi yang menampilkan error prasyarat gagal, seperti pelanggaran indeks UNIQUE, baris sudah ada, atau baris tidak ditemukan.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT INT64 Jumlah total upaya transaksi yang dimulai dengan tingkat isolasi SERIALIZABLE dan penguncian PESSIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT INT64 Jumlah total upaya transaksi yang dimulai dengan tingkat isolasi REPEATABLE READ dan penguncian OPTIMISTIC. Ini adalah subset dari ATTEMPT_COUNT.
AVG_PARTICIPANTS FLOAT64 Jumlah rata-rata peserta dalam setiap upaya commit. Untuk mempelajari lebih lanjut peserta, lihat Proses Operasi Baca & Tulis Spanner.
AVG_TOTAL_LATENCY_SECONDS FLOAT64 Rata-rata detik yang diperlukan dari operasi pertama transaksi hingga commit/pembatalan.
AVG_COMMIT_LATENCY_SECONDS FLOAT64 Rata-rata detik yang diperlukan untuk melakukan operasi commit.
AVG_BYTES FLOAT64 Jumlah rata-rata byte yang ditulis oleh transaksi.
TOTAL_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau pembatalan untuk semua upaya transaksi.

Jika transaksi dibatalkan beberapa kali dan kemudian berhasil di-commit, latensi akan diukur untuk setiap upaya hingga commit terakhir yang berhasil. Nilai diukur dalam detik.

Array berisi satu elemen dan memiliki jenis berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Untuk mengetahui informasi selengkapnya tentang nilai, lihat Distribution dan Exponential.

Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Sebagai contoh, lihat Menemukan latensi persentil ke-99 untuk transaksi.

Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.

OPERATIONS_BY_TABLE ARRAY<STRUCT>

Dampak operasi INSERT atau UPDATE oleh semua transaksi per tabel. Hal ini ditunjukkan dengan frekuensi baris terpengaruh dan jumlah byte yang ditulis.

Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

Tentukan array sebagai berikut:
ARRAY<STRUCT<
  TABLE STRING(MAX),
  INSERT_OR_UPDATE_COUNT INT64,
  INSERT_OR_UPDATE_BYTES INT64>>

TOTAL_LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogram total latensi commit, yaitu waktu dari waktu mulai operasi transaksional pertama hingga waktu commit atau pembatalan, untuk semua upaya transaksi.

Representasi string yang kompatibel dengan JSON dari statistik TOTAL_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan dalam TOTAL_LATENCY_DISTRIBUTION.

Jika transaksi dibatalkan beberapa kali dan kemudian berhasil di-commit, latensi akan diukur untuk setiap upaya hingga commit terakhir berhasil. Nilai diukur dalam detik.

Kolom ini didukung dalam database dialek GoogleSQL dan dialek PostgreSQL. Kolom ini berisi Distribusi.

Untuk menghitung latensi persentil dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), yang menampilkan perkiraan persentil ke-n. Untuk contoh terkait, lihat Menemukan latensi persentil ke-99 untuk transaksi menggunakan kolom TOTAL_LATENCY_DISTRIBUTION_JSON_STRING.

Untuk mengetahui informasi selengkapnya, lihat Persentil dan metrik bernilai distribusi.

OPERATIONS_BY_TABLE_JSON_STRING STRING

Dampak operasi INSERT atau UPDATE oleh transaksi berdasarkan per tabel. Hal ini ditunjukkan dengan frekuensi baris terpengaruh dan jumlah byte yang ditulis.

Representasi string yang kompatibel dengan JSON dari kolom OPERATIONS_BY_TABLE. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom OPERATIONS_BY_TABLE.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Kolom ini membantu memvisualisasikan beban pada tabel dan memberikan insight tentang kecepatan transaksi menulis ke tabel.

COMMIT_LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogram jumlah detik yang diperlukan untuk melakukan operasi commit.

Array memiliki struktur berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Untuk mengetahui informasi selengkapnya tentang jenis nilai, lihat Distribusi dan Eksponensial.

Untuk menghitung persentil latensi commit dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

COMMIT_LATENCY_DISTRIBUTION_JSON_STRING STRING

Representasi string yang kompatibel dengan JSON dari statistik COMMIT_LATENCY_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom COMMIT_LATENCY_DISTRIBUTION.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Untuk menghitung persentil latensi commit dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

PARTICIPANTS_DISTRIBUTION ARRAY<STRUCT>

Histogram jumlah peserta dalam setiap upaya commit.

Array memiliki struktur berikut:
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Untuk mengetahui informasi selengkapnya tentang jenis nilai, lihat Distribusi dan Eksponensial.

Untuk menghitung persentil peserta dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

PARTICIPANTS_DISTRIBUTION_JSON_STRING STRING

Representasi string yang kompatibel dengan JSON dari statistik PARTICIPANTS_DISTRIBUTION. String JSON adalah objek JSON dengan struktur yang sama dengan STRUCT yang ditentukan di kolom PARTICIPANTS_DISTRIBUTION.

Kolom ini didukung di database dialek GoogleSQL dan dialek PostgreSQL.

Untuk menghitung persentil peserta dari distribusi, gunakan fungsi SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Contoh kueri

Bagian ini mencakup beberapa contoh pernyataan SQL yang mengambil statistik transaksi. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsolGoogle Cloud .

Menemukan jumlah total upaya commit untuk semua transaksi

Kueri berikut menampilkan jumlah total upaya commit untuk semua transaksi dalam interval 1 menit lengkap terbaru:

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;
Output kueri
interval_end commit_attempt_count
2020-01-17 11:46:00-08:00 21

Perhatikan bahwa hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu apa pun.

Menemukan total latensi commit di semua transaksi

Kueri berikut menampilkan total latensi commit di semua transaksi dalam 10 menit sebelumnya:

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);
Output kueri
total_commit_latency_hours
0.8967

Perhatikan bahwa hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu apa pun.

Menemukan latensi persentil ke-99 untuk transaksi

Kueri berikut menampilkan persentil ke-99 waktu eksekusi di seluruh kueri yang dijalankan dalam 10 menit sebelumnya.

Untuk database dialek GoogleSQL, Anda dapat menggunakan kolom TOTAL_LATENCY_DISTRIBUTION:

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;

Untuk database dialek PostgreSQL, gunakan kolom TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 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;
Output kueri
interval_end avg_total_latency_seconds percentile_latency
2022-08-17 11:46:00-08:00 0.34576998305986395 9.00296190476190476

Perhatikan perbedaan besar antara latensi rata-rata dan persentil ke-99. Latensi persentil ke-99 membantu mengidentifikasi kemungkinan transaksi pencilan dengan latensi tinggi.

Hanya ada satu baris dalam hasil karena statistik gabungan hanya memiliki satu entri per interval_end untuk durasi waktu berapa pun.

Retensi data

Setidaknya, Spanner menyimpan data untuk setiap tabel selama jangka waktu berikut:

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE dan SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Interval yang mencakup 6 jam sebelumnya.

  • SPANNER_SYS.TXN_STATS_TOP_10MINUTE dan SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Interval yang mencakup 4 hari sebelumnya.

  • SPANNER_SYS.TXN_STATS_TOP_HOUR dan SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Interval yang mencakup 30 hari sebelumnya.

Statistik transaksi di Spanner memberikan insight tentang cara aplikasi menggunakan database, dan berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa apakah ada transaksi yang berjalan lambat yang mungkin menyebabkan pertentangan, atau Anda dapat mengidentifikasi potensi sumber beban tinggi, seperti update dalam jumlah besar ke kolom tertentu.

Memahami transaksi dan jumlah commit

Transaksi Spanner mungkin harus dicoba beberapa kali sebelum di-commit. Hal ini paling sering terjadi saat dua transaksi mencoba mengerjakan data yang sama pada saat yang sama, dan salah satu transaksi harus dibatalkan untuk mempertahankan properti isolasi transaksi. Beberapa peristiwa sementara lainnya yang juga dapat menyebabkan transaksi dibatalkan meliputi:

  • Masalah jaringan sementara.

  • Perubahan skema database diterapkan saat transaksi sedang dalam proses commit.

  • Instance Spanner tidak memiliki kapasitas untuk menangani semua permintaan yang diterimanya.

Dalam skenario seperti ini, klien harus mencoba ulang transaksi yang dibatalkan hingga transaksi berhasil di-commit atau waktu tunggu habis. Untuk pengguna library klien Spanner resmi, setiap library telah menerapkan mekanisme percobaan ulang otomatis. Jika Anda menggunakan versi kustom kode klien, gabungkan commit transaksi Anda dalam loop percobaan ulang.

Transaksi Spanner juga dapat dibatalkan karena error yang tidak dapat dicoba ulang, seperti waktu tunggu transaksi habis, masalah izin, atau nama tabel atau kolom yang tidak valid. Tidak perlu mencoba ulang transaksi tersebut dan library klien Spanner akan segera menampilkan error.

Tabel berikut menjelaskan beberapa contoh cara COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT, dan COMMIT_RETRY_COUNT dicatat dalam berbagai skenario.

Skenario COMMIT_ATTEMPT_COUNT COMMIT_ABORT_COUNT COMMIT_RETRY_COUNT
Transaksi berhasil di-commit pada percobaan pertama. 1 0 0
Transaksi dibatalkan karena error waktu habis. 1 1 0
Transaksi dibatalkan karena masalah jaringan sementara dan berhasil di-commit setelah satu kali percobaan ulang. 2 1 1
5 transaksi dengan FPRINT yang sama dijalankan dalam interval 10 menit. 3 transaksi berhasil di-commit pada percobaan pertama, sementara 2 transaksi dibatalkan dan kemudian berhasil di-commit pada percobaan ulang pertama. 7 2 2

Data dalam tabel transaction-stats adalah data gabungan untuk interval waktu. Untuk interval tertentu, pembatalan dan percobaan ulang transaksi mungkin terjadi di sekitar batas dan masuk ke bucket yang berbeda. Akibatnya, dalam interval waktu tertentu, pembatalan dan percobaan ulang mungkin tidak sama.

Statistik ini dirancang untuk pemecahan masalah dan introspeksi, serta tidak dijamin 100% akurat. Statistik digabungkan dalam memori sebelum disimpan dalam tabel Spanner. Selama upgrade atau aktivitas pemeliharaan lainnya, server Spanner dapat dimulai ulang, sehingga memengaruhi akurasi angka.

Memecahkan masalah pertentangan database menggunakan statistik transaksi

Anda dapat menggunakan kode SQL atau dasbor Transaction insights untuk melihat transaksi dalam database yang mungkin menyebabkan latensi tinggi karena pertentangan kunci.

Topik berikut menunjukkan cara menyelidiki transaksi tersebut menggunakan kode SQL.

Pilih jangka waktu yang akan diselidiki

Hal ini dapat ditemukan dari aplikasi yang menggunakan Spanner.

Untuk tujuan latihan ini, asumsikan bahwa masalah mulai terjadi sekitar pukul 17.20 pada tanggal 17 Mei 2020.

Anda dapat menggunakan Tag Transaksi untuk mengidentifikasi sumber transaksi dan menghubungkan antara Tabel Statistik Transaksi dan tabel Statistik Kunci untuk pemecahan masalah pertentangan kunci yang efektif. Baca selengkapnya di Memecahkan masalah dengan tag transaksi.

Mengumpulkan statistik transaksi untuk jangka waktu yang dipilih

Untuk memulai investigasi, buat kueri tabel TXN_STATS_TOTAL_10MINUTE di sekitar awal masalah. Hasil kueri ini menunjukkan bagaimana latensi dan statistik transaksi lainnya berubah selama jangka waktu tersebut.

Misalnya, kueri berikut menampilkan statistik transaksi gabungan dari 4:30 pm hingga 7:40 pm (inklusif).

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;

Tabel berikut mencantumkan contoh data yang ditampilkan dari kueri.

interval_end avg_total_latency_seconds commit_attempt_count commit_abort_count
2020-05-17 16:40:00-07:00 0,0284 315691 5170
2020-05-17 16:50:00-07:00 0,0250 302124 3828
17-05-2020 17:00:00-07:00 0,0460 346087 11382
17-05-2020 17:10:00-07:00 0,0864 379964 33826
2020-05-17 17:20:00-07:00 0,1291 390343 52549
2020-05-17 17:30:00-07:00 0,1314 456455 76392
2020-05-17 17:40:00-07:00 0,1598 507774 121458
2020-05-17 17:50:00-07:00 0,1641 516587 115875
2020-05-17 18:00:00-07:00 0,1578 552711 122626
2020-05-17 18:10:00-07:00 0,1750 569460 154205
2020-05-17 18:20:00-07:00 0,1727 613571 160772
2020-05-17 18:30:00-07:00 0,1588 601994 143044
2020-05-17 18:40:00-07:00 0,2025 604211 170019
2020-05-17 18:50:00-07:00 0,1615 601622 135601
2020-05-17 19:00:00-07:00 0,1653 596804 129511
2020-05-17 19:10:00-07:00 0.1414 560023 112247
2020-05-17 19:20:00-07:00 0,1367 570864 100596
2020-05-17 19:30:00-07:00 0,0894 539729 65316
2020-05-17 19:40:00-07:00 0,0820 479151 40398

Latensi gabungan dan jumlah pembatalan lebih tinggi dalam periode yang ditandai. Pilih interval 10 menit saat latensi gabungan dan jumlah pembatalan atau keduanya tinggi. Interval yang berakhir pada 2020-05-17T18:40:00 digunakan pada langkah berikutnya untuk mengidentifikasi transaksi mana yang berkontribusi pada latensi tinggi dan jumlah pembatalan.

Mengidentifikasi transaksi yang mengalami latensi tinggi

Buat kueri tabel TXN_STATS_TOP_10MINUTE untuk interval yang dipilih pada langkah sebelumnya. Dengan menggunakan data ini, Anda dapat mulai mengidentifikasi transaksi mana yang mengalami latensi tinggi atau jumlah pembatalan yang tinggi, atau keduanya.

Jalankan kueri berikut untuk mendapatkan transaksi yang paling berdampak pada performa dalam urutan menurun dari total latensi untuk contoh interval yang berakhir pada 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;
interval_end fprint avg_total_latency_seconds avg_commit_latency_seconds commit_attempt_count commit_abort_count commit_retry_count
2020-05-17 18:40:00-07:00 15185072816865185658 0,3508 0,0139 278802 142205 129884
2020-05-17 18:40:00-07:00 15435530087434255496 0,1633 0,0142 129012 27177 24559
2020-05-17 18:40:00-07:00 14175643543447671202 0,1423 0,0133 5357 636 433
2020-05-17 18:40:00-07:00 898069986622520747 0,0198 0,0158 6 0 0
2020-05-17 18:40:00-07:00 10510121182038036893 0,0168 0,0125 7 0 0
2020-05-17 18:40:00-07:00 9287748709638024175 0,0159 0,0118 4269 1 0
2020-05-17 18:40:00-07:00 7129109266372596045 0,0142 0,0102 182227 0 0
2020-05-17 18:40:00-07:00 15630228555662391800 0,0120 0,0107 58 0 0
2020-05-17 18:40:00-07:00 7907238229716746451 0,0108 0,0097 65 0 0
2020-05-17 18:40:00-07:00 10158167220149989178 0,0095 0,0047 3454 0 0
2020-05-17 18:40:00-07:00 9353100217060788102 0,0093 0,0045 725 0 0
2020-05-17 18:40:00-07:00 9521689070912159706 0,0093 0,0045 164 0 0
2020-05-17 18:40:00-07:00 11079878968512225881 0,0064 0,0019 65 0 0

Baris pertama (ditandai) dalam tabel sebelumnya menunjukkan transaksi yang mengalami latensi tinggi karena tingginya jumlah pembatalan commit. Ada juga jumlah percobaan ulang commit yang tinggi, yang menunjukkan bahwa commit yang dibatalkan kemudian dicoba ulang. Langkah berikutnya adalah menyelidiki lebih lanjut untuk melihat penyebab masalah ini.

Mengidentifikasi kolom yang terlibat dalam transaksi yang mengalami latensi tinggi

Pada langkah ini, periksa apakah transaksi latensi tinggi beroperasi pada set kolom yang sama dengan mengambil data read_columns, write_constructive_columns, dan write_delete_tables untuk transaksi dengan jumlah pembatalan yang tinggi. Nilai FPRINT juga akan berguna di langkah berikutnya.

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;
fprint read_columns write_constructive_columns write_delete_tables
15185072816865185658 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares] [TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares] []
15435530087434255496 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] [TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes] []
14175643543447671202 [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] [TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount] []

Seperti yang ditunjukkan oleh output pada tabel sebelumnya, transaksi dengan total latensi rata-rata tertinggi membaca kolom yang sama. Ada juga beberapa pertentangan tulis karena transaksi menulis ke kolom yang sama, yaitu TestHigherLatency._exists.

Menentukan perubahan performa transaksi dari waktu ke waktu

Anda dapat melihat perubahan statistik yang terkait dengan bentuk transaksi ini selama jangka waktu tertentu. Gunakan kueri berikut, dengan $FPRINT adalah sidik jari transaksi latensi tinggi dari langkah sebelumnya.

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;
interval_end latensi commit_latency commit_attempt_count commit_abort_count commit_retry_count commit_failed_precondition_count avg_bytes
2020-05-17 16:40:00-07:00 0,095 0,010 53230 4752 4330 0 91
2020-05-17 16:50:00-07:00 0,069 0,009 61264 3589 3364 0 91
17-05-2020 17:00:00-07:00 0,150 0,010 75868 10557 9322 0 91
17-05-2020 17:10:00-07:00 0,248 0,013 103151 30220 28483 0 91
17-05-2020 17:20:00-07:00 0,310 0,012 130078 45655 41966 0 91
2020-05-17 17:30:00-07:00 0,294 0,012 160064 64930 59933 0 91
2020-05-17 17:40:00-07:00 0,315 0,013 209614 104949 96770 0 91
17-05-2020 17:50:00-07:00 0,322 0,012 215682 100408 95867 0 90
17-05-2020 18:00:00-07:00 0,310 0,012 230932 106728 99462 0 91
17-05-2020 18:10:00-07:00 0,309 0,012 259645 131049 125889 0 91
17-05-2020 18:20:00-07:00 0,315 0,013 272171 137910 129411 0 90
2020-05-17 18:30:00-07:00 0,292 0,013 258944 121475 115844 0 91
2020-05-17 18:40:00-07:00 0,350 0,013 278802 142205 134229 0 91
2020-05-17 18:50:00-07:00 0,302 0,013 256259 115626 109756 0 91
17-05-2020 19:00:00-07:00 0,315 0,014 250560 110662 100322 0 91
17-05-2020 19:10:00-07:00 0,271 0,014 238384 99025 90187 0 91
17-05-2020 19:20:00-07:00 0,273 0,014 219687 84019 79874 0 91
2020-05-17 19:30:00-07:00 0,198 0,013 195357 59370 55909 0 91
2020-05-17 19:40:00-07:00 0,181 0,013 167514 35705 32885 0 91

Dalam output ini, perhatikan bahwa total latensi tinggi untuk jangka waktu yang ditandai. Selain itu, di mana pun total latensi tinggi, commit_attempt_count, commit_abort_count, dan commit_retry_count juga tinggi meskipun latensi commit (commit_latency) tidak banyak berubah. Karena commit transaksi lebih sering dibatalkan, upaya commit juga tinggi karena percobaan ulang commit.

Kesimpulan

Dalam contoh ini, jumlah pembatalan commit yang tinggi adalah penyebab latensi tinggi. Langkah berikutnya adalah melihat pesan error pembatalan commit yang diterima oleh aplikasi untuk mengetahui alasan pembatalan. Dengan memeriksa log dalam aplikasi, Anda dapat melihat bahwa aplikasi benar-benar mengubah workload-nya selama waktu ini, yaitu, beberapa bentuk transaksi lain muncul dengan attempts_per_second yang tinggi, dan transaksi yang berbeda tersebut (mungkin tugas pembersihan malam hari) bertanggung jawab atas konflik penguncian tambahan.

Mengidentifikasi transaksi yang tidak dicoba ulang dengan benar

Kueri berikut menampilkan transaksi yang diambil sampelnya dalam sepuluh menit terakhir yang memiliki jumlah pembatalan commit yang tinggi, tetapi tidak ada percobaan ulang.

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 total_commit_attempt_count total_commit_abort_count total_commit_retry_count
1557557373282541312 3367894 44232 0
5776062322886969344 13566 14 0

Transaksi dengan fprint 1557557373282541312 dibatalkan 44.232 kali, tetapi tidak pernah dicoba lagi. Hal ini terlihat mencurigakan karena jumlah pembatalan tinggi dan kecil kemungkinan setiap pembatalan disebabkan oleh error yang tidak dapat dicoba ulang. Di sisi lain, untuk transaksi dengan fprint 5776062322886969344, transaksi ini kurang mencurigakan karena jumlah total pembatalan tidak terlalu tinggi.

Kueri berikut menampilkan detail selengkapnya tentang transaksi dengan fprint 1557557373282541312 termasuk read_columns,write_constructive_columns, dan write_delete_tables. Informasi ini membantu mengidentifikasi transaksi dalam kode klien, tempat logika percobaan ulang dapat ditinjau untuk skenario ini.

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;
interval_end fprint read_columns write_constructive_columns write_delete_tables commit_attempt_count commit_abort_count commit_retry_count
2021-01-27T18:30:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 805228 1839 0
2021-01-27T18:20:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 1034429 38779 0
2021-01-27T18:10:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 833677 2266 0
2021-01-27T18:00:00Z 1557557373282541312 ['Singers._exists'] ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] [] 694560 1348 0

Transaksi ini melibatkan pembacaan ke kolom tersembunyi Singers._exists untuk memeriksa keberadaan baris. Transaksi juga menulis ke kolom Singers.FirstName dan Singer.LastName. Informasi ini dapat membantu menentukan apakah mekanisme percobaan ulang transaksi yang diterapkan di library klien kustom Anda berfungsi seperti yang diharapkan.

Langkah berikutnya