Statistik operasi baca

Spanner menyediakan tabel bawaan yang menyimpan statistik tentang pembacaan. Anda dapat mengambil statistik dari tabel SPANNER_SYS.READ_STATS* ini menggunakan pernyataan SQL.

Kapan harus menggunakan statistik baca

Statistik baca memberikan insight tentang cara aplikasi menggunakan database, dan berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa bentuk operasi baca yang berjalan di database, frekuensinya berjalan, dan menjelaskan karakteristik performa bentuk operasi baca ini. Anda dapat menggunakan statistik baca untuk database guna mengidentifikasi bentuk baca yang menghasilkan penggunaan CPU tinggi. Secara umum, statistik baca akan membantu Anda memahami perilaku traffic yang masuk ke database dalam hal penggunaan resource.

Batasan

  • Alat ini paling cocok untuk menganalisis aliran pembacaan serupa yang mencakup sebagian besar penggunaan CPU. Ini tidak baik untuk menelusuri pembacaan yang hanya dijalankan satu kali.

  • Penggunaan CPU yang dilacak dalam statistik ini mewakili penggunaan CPU sisi server Spanner, tidak termasuk penggunaan CPU pengambilan data sebelumnya dan beberapa overhead lainnya.

  • Statistik dikumpulkan berdasarkan upaya terbaik. Akibatnya, statistik dapat terlewat jika ada masalah pada sistem yang mendasarinya. Misalnya, jika ada masalah jaringan internal, beberapa statistik mungkin tidak terkumpul.

Ketersediaan

Data SPANNER_SYS hanya tersedia melalui antarmuka SQL; misalnya:

  • Halaman Spanner Studio database di konsol Google Cloud

  • Perintah gcloud spanner databases execute-sql

  • executeQuery API

Metode baca tunggal lainnya yang disediakan Spanner tidak mendukung SPANNER_SYS.

Penggunaan CPU yang dikelompokkan menurut bentuk operasi baca

Tabel berikut melacak bentuk baca dengan penggunaan CPU tertinggi selama jangka waktu tertentu:

  • SPANNER_SYS.READ_STATS_TOP_MINUTE: Statistik bentuk baca yang digabungkan dalam interval 1 menit.
  • SPANNER_SYS.READ_STATS_TOP_10MINUTE: Membaca statistik bentuk yang digabungkan di seluruh interval 10 menit.
  • SPANNER_SYS.READ_STATS_TOP_HOUR: Statistik bentuk baca yang digabungkan dalam interval 1 jam.

Tabel ini memiliki properti berikut:

  • Setiap tabel berisi data untuk interval waktu yang tidak tumpang-tindih dengan durasi yang ditentukan 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. Setelah setiap interval, Spanner mengumpulkan data dari semua server, lalu menyediakan data tersebut di tabel SPANNER_SYS tidak lama setelah itu.

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

    • 1 menit: 00.58.00–00.58.59
    • 10 menit: 11.40.00–11.49.59
    • 1 jam: 10.00.00–10.59.59

  • Spanner mengelompokkan statistik berdasarkan bentuk operasi baca. Jika tag ada, FPRINT adalah hash tag. Jika tidak, nilainya adalah hash dari nilai READ_COLUMNS.

  • Setiap baris berisi statistik untuk semua eksekusi bentuk operasi baca tertentu yang statistiknya diambil oleh Spanner selama interval yang ditentukan.

  • Jika Spanner tidak dapat menyimpan informasi tentang setiap bentuk pembacaan yang berbeda yang dijalankan selama interval, sistem akan memprioritaskan bentuk pembacaan dengan penggunaan CPU tertinggi selama interval yang ditentukan.

Skema tabel

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu terjadinya eksekusi baca yang disertakan.
REQUEST_TAG STRING Tag permintaan opsional untuk operasi baca ini. Untuk informasi selengkapnya tentang cara menggunakan tag, lihat Pemecahan masalah dengan tag permintaan. Statistik untuk beberapa operasi baca yang memiliki string tag yang sama dikelompokkan dalam satu baris dengan `REQUEST_TAG` yang cocok dengan string tag tersebut.
READ_TYPE STRING Menunjukkan apakah operasi baca adalah PARTITIONED_READ atau READ. Operasi baca dengan partitionToken yang diperoleh dari PartitionRead API direpresentasikan oleh jenis baca PARTITIONED_READ dan API baca lainnya dengan READ.
READ_COLUMNS ARRAY<STRING> Kumpulan kolom yang dibaca. Data ini disusun menurut abjad.
FPRINT INT64 Hash nilai REQUEST_TAG jika ada; Jika tidak, hash nilai READ_COLUMNS.
EXECUTION_COUNT INT64 Frekuensi Spanner mengeksekusi bentuk operasi baca selama interval.
AVG_ROWS FLOAT64 Jumlah rata-rata baris yang ditampilkan oleh operasi baca.
AVG_BYTES FLOAT64 Jumlah rata-rata byte data yang ditampilkan operasi baca, tidak termasuk overhead encoding transmisi.
AVG_CPU_SECONDS FLOAT64 Jumlah rata-rata detik CPU sisi server Spanner yang mengeksekusi operasi baca, tidak termasuk CPU pengambilan data sebelumnya dan overhead lainnya.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Jumlah detik rata-rata yang dihabiskan untuk menunggu karena penguncian.
AVG_CLIENT_WAIT_SECONDS FLOAT64 Jumlah rata-rata detik yang dihabiskan untuk menunggu karena klien tidak menggunakan data secepat yang dapat dihasilkan Spanner.
AVG_LEADER_REFRESH_DELAY_SECONDS FLOAT64 Jumlah rata-rata detik yang dihabiskan untuk menunggu konfirmasi dari pemimpin Paxos bahwa semua operasi tulis telah diamati.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Frekuensi operasi baca dijalankan sebagai bagian dari transaksi baca-tulis. Kolom ini membantu Anda menentukan apakah Anda dapat menghindari pertentangan kunci dengan memindahkan operasi baca ke transaksi hanya baca.

Contoh kueri

Bagian ini menyertakan beberapa contoh pernyataan SQL yang mengambil statistik baca. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsol Google Cloud.

Mencantumkan statistik dasar untuk setiap bentuk operasi baca dalam jangka waktu tertentu

Kueri berikut menampilkan data mentah untuk bentuk pembacaan teratas dalam interval waktu 1 menit terbaru.

SELECT fprint,
       read_columns,
       execution_count,
       avg_cpu_seconds,
       avg_rows,
       avg_bytes,
       avg_locking_delay_seconds,
       avg_client_wait_seconds
FROM spanner_sys.read_stats_top_minute
ORDER BY interval_end DESC LIMIT 3;
Output kueri
fprint read_columns execution_count avg_cpu_seconds avg_rows avg_bytes avg_locking_delay_seconds avg_client_wait_seconds
125062082139 ["Singers.id", "Singers.name"] 8514387 0.000661355290396507 310.79 205 8.3232564943763752e-06 0
151238888745 ["Singers.singerinfo"] 3341542 6.5992827184280315e-05 12784 54 4.6859741349028595e-07 0
14105484 ["Albums.id", "Albums.title"] 9306619 0.00017855774721667873 1165.4 2964.71875 1.4328191393074178e-06 0

Mencantumkan bentuk baca, yang diurutkan berdasarkan penggunaan CPU total tertinggi

Kueri berikut menampilkan bentuk baca dengan penggunaan CPU tertinggi dalam jam terakhir:

SELECT read_columns,
       execution_count,
       avg_cpu_seconds,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.read_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_top_hour)
ORDER BY total_cpu DESC LIMIT 3;
Output kueri
read_columns execution_count avg_cpu_seconds total_cpu
["Singers.id", "Singers.name"] 1647 0.00023380297430622681 0.2579
["Albums.id", "Albums.title"] 720 0.00016738889440282034 0.221314999999999
["Singers.singerinfo""] 3223 0.00037764625882302246 0.188053

Statistik gabungan

SPANNER_SYS juga berisi tabel untuk menyimpan statistik operasi baca gabungan yang diambil oleh Spanner dalam jangka waktu tertentu:

  • SPANNER_SYS.READ_STATS_TOTAL_MINUTE: Statistik gabungan untuk semua bentuk baca selama interval 1 menit.
  • SPANNER_SYS.READ_STATS_TOTAL_10MINUTE: Statistik gabungan untuk semua bentuk baca selama interval 10 menit.
  • SPANNER_SYS.READ_STATS_TOTAL_HOUR: Statistik gabungan untuk semua bentuk baca 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 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 23.59.30, interval terbaru yang tersedia untuk kueri SQL pada statistik baca gabungan adalah:

    • 1 menit: 00.58.00–00.58.59
    • 10 menit: 11.40.00–11.49.59
    • 1 jam: 10.00.00–10.59.59

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

  • Statistik yang diambil dalam tabel SPANNER_SYS.READ_STATS_TOTAL_* mungkin menyertakan bentuk baca yang tidak diambil Spanner dalam tabel SPANNER_SYS.READ_STATS_TOP_*.

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

    • Jumlah baris yang ditampilkan
    • Jumlah eksekusi baca
    • Waktu CPU baca
    • Penundaan penguncian
    • Waktu tunggu klien
    • Penundaan pembaruan pemimpin
    • Jumlah byte yang ditampilkan

    Untuk informasi selengkapnya, lihat Metrik Spanner.

Skema tabel

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu tempat eksekusi bentuk baca yang disertakan terjadi.
EXECUTION_COUNT INT64 Frekuensi Spanner mengeksekusi bentuk operasi baca selama interval.
AVG_ROWS FLOAT64 Jumlah rata-rata baris yang ditampilkan oleh operasi baca.
AVG_BYTES FLOAT64 Jumlah rata-rata byte data yang ditampilkan pembacaan, tidak termasuk overhead encoding transmisi.
AVG_CPU_SECONDS FLOAT64 Jumlah rata-rata detik CPU sisi server Spanner yang mengeksekusi operasi baca, tidak termasuk CPU pengambilan data sebelumnya dan overhead lainnya.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Jumlah detik rata-rata yang dihabiskan untuk menunggu karena penguncian.
AVG_CLIENT_WAIT_SECONDS FLOAT64 Jumlah detik rata-rata yang dihabiskan untuk menunggu karena throttling.
AVG_LEADER_REFRESH_DELAY_SECONDS FLOAT64 Jumlah rata-rata detik yang dihabiskan untuk mengoordinasikan operasi baca di seluruh instance dalam konfigurasi multi-region.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Frekuensi pembacaan dijalankan sebagai bagian dari transaksi baca-tulis. Kolom ini membantu Anda menentukan apakah Anda dapat menghindari pertentangan kunci dengan memindahkan beberapa operasi baca ke transaksi hanya baca.

Contoh kueri

Bagian ini menyertakan beberapa contoh pernyataan SQL yang mengambil statistik pembacaan gabungan. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau konsol Google Cloud.

Menemukan total penggunaan CPU di semua bentuk baca

Kueri berikut menampilkan jumlah jam CPU yang digunakan oleh bentuk baca dalam jam terbaru:

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.read_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_total_hour);
Output kueri
total_cpu_hours
0.00026186111111111115

Menemukan total jumlah eksekusi dalam jangka waktu tertentu

Kueri berikut menampilkan jumlah total bentuk baca yang dieksekusi dalam interval 1 menit lengkap terbaru:

SELECT interval_end,
       execution_count
FROM spanner_sys.read_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.read_stats_total_minute);
Output kueri
interval_end execution_count
2020-05-28 11:02:00-07:00 12861966

Retensi data

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

  • SPANNER_SYS.READ_STATS_TOP_MINUTE dan SPANNER_SYS.READ_STATS_TOTAL_MINUTE: Interval yang mencakup 6 jam sebelumnya.

  • SPANNER_SYS.READ_STATS_TOP_10MINUTE dan SPANNER_SYS.READ_STATS_TOTAL_10MINUTE: Interval yang mencakup 4 hari sebelumnya.

  • SPANNER_SYS.READ_STATS_TOP_HOUR dan SPANNER_SYS.READ_STATS_TOTAL_HOUR: Interval yang mencakup 30 hari sebelumnya.

Memecahkan masalah penggunaan CPU yang tinggi dengan statistik baca

Statistik operasi baca Spanner sangat berguna jika Anda perlu menyelidiki penggunaan CPU yang tinggi di database Spanner atau saat Anda hanya mencoba memahami bentuk operasi baca yang berat CPU di database. Pemeriksaan bentuk operasi baca yang menggunakan resource database dalam jumlah yang signifikan memberi pengguna Spanner potensi cara untuk mengurangi biaya operasional dan mungkin meningkatkan latensi sistem umum. Dengan langkah-langkah berikut, kami akan menunjukkan cara menggunakan statistik baca untuk menyelidiki penggunaan CPU yang tinggi di database Anda.

Memilih jangka waktu untuk diselidiki

Mulai investigasi dengan mencari waktu saat aplikasi Anda mulai mengalami penggunaan CPU yang tinggi. Misalnya, dalam skenario berikut, masalah mulai terjadi sekitar pukul 17.20 pada 28 Mei 2020.

Mengumpulkan statistik baca untuk jangka waktu yang dipilih

Setelah memilih jangka waktu untuk memulai investigasi, kita akan melihat statistik yang dikumpulkan dalam tabel READ_STATS_TOTAL_10MINUTE sekitar waktu tersebut. Hasil kueri ini dapat memberi kita petunjuk tentang bagaimana CPU dan statistik baca lainnya berubah selama jangka waktu tersebut. Kueri berikut menampilkan statistik baca gabungan dari 4:30 pm hingga 7:30 pm (inklusif).

SELECT
  interval_end,
  ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
  execution_count,
  avg_locking_delay_seconds
FROM SPANNER_SYS.READ_STATS_TOTAL_10MINUTE
WHERE
  interval_end >= "2020-05-28T16:30:00"
  AND interval_end <= "2020-05-28T19:30:00"
ORDER BY interval_end;

Data berikut adalah contoh hasil yang kita dapatkan dari kueri.

interval_end avg_cpu_seconds execution_count avg_locking_delay_seconds
2020-05-28 16:40:00-07:00 0,0004 11111421 8.3232564943763752e-06
28-05-2020 16:50:00-07:00 0,0002 8815637 8,98734051776406e-05
28-05-2020 17:00:00-07:00 0,0001 8260215 6.039129247846453e-06
28-05-2020 17.10.00-07.00 0,0001 8514387 9,0535466616680686e-07
2020-05-28 17:20:00-07:00 0,0006 13715466 2,6801485272173765e-06
2020-05-28 17:30:00-07:00 0,0007 12861966 4,6859741349028595e-07
2020-05-28 17:40:00-07:00 0,0007 3755954 2,7131391918005383e-06
2020-05-28 17:50:00-07:00 0,0006 4248137 1,4328191393074178e-06
2020-05-28 18:00:00-07:00 0,0006 3986198 2,6973481999639748e-06
2020-05-28 18:10:00-07:00 0,0006 3510249 3,7577083563017905e-06
28-05-2020 18:20:00-07:00 0,0004 3341542 4,0940589703795433e-07
28-05-2020 18:30:00-07:00 0,0002 8695147 1,9914494947583975e-05
28-05-2020 18:40:00-07:00 0,0003 11679702 1,8331461539001595e-05
28-05-2020 18.50.00-07.00 0,0003 9306619 1,2527332321222135e-05
28-05-2020 19:00:00-07:00 0,0002 8520508 6.2268448078447915e-06
2020-05-28 19:10:00-07:00 0,0006 13715466 2,6801485272173765e-06
2020-05-28 19:20:00-07:00 0,0005 11947323 3.3029114639321295e-05
28-05-2020 19:30:00-07:00 0,0002 8514387 9,0535466616680686e-07

Di sini kita melihat bahwa waktu CPU rata-rata, avg_cpu_seconds, lebih tinggi dalam interval yang ditandai. interval_end dengan nilai 2020-05-28 19:20:00 memiliki waktu CPU yang lebih tinggi, jadi kita akan memilih interval tersebut untuk diinvestigasi lebih lanjut di langkah berikutnya.

Menemukan bentuk operasi baca yang menyebabkan penggunaan CPU tinggi

Untuk mempelajari lebih lanjut, sekarang kita membuat kueri tabel READ_STATS_TOP_10MINUTE untuk interval yang dipilih pada langkah sebelumnya. Hasil kueri ini dapat membantu menunjukkan bentuk operasi baca yang menyebabkan penggunaan CPU tinggi.

SELECT
  read_columns,
  ROUND(avg_cpu_seconds,4) as avg_cpu_seconds,
  execution_count,
  avg_rows
FROM SPANNER_SYS.READ_STATS_TOP_10MINUTE
WHERE
  interval_end = "2020-05-28T19:20:00"
ORDER BY avg_cpu_seconds DESC LIMIT 3;

Data berikut sebagai contoh hasil yang kita dapatkan dari kueri, yang menampilkan informasi tentang tiga bentuk baca teratas yang diberi peringkat oleh avg_cpu_seconds. Perhatikan penggunaan ROUND dalam kueri kita untuk membatasi output avg_cpu_seconds menjadi 4 angka di belakang koma.

read_columns avg_cpu_seconds execution_count avg_rows
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares]1 0,4192 1182 11650.42216582
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] 0,0852 4 12784
[TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] 0,0697 1140 310,7921052631

1 _exists adalah kolom internal yang digunakan untuk memeriksa apakah baris tertentu ada atau tidak.

Salah satu alasan penggunaan CPU yang tinggi mungkin karena Anda mulai menjalankan beberapa bentuk baca lebih sering (execution_count). Mungkin jumlah rata-rata baris yang ditampilkan oleh operasi baca telah meningkat (avg_rows). Jika tidak ada properti bentuk baca yang mengungkapkan sesuatu yang menarik, Anda dapat memeriksa properti lain seperti avg_locking_delay_seconds, avg_client_wait_seconds, atau avg_bytes.

Menerapkan praktik terbaik untuk mengurangi penggunaan CPU yang tinggi

Setelah Anda melakukan langkah-langkah sebelumnya, pertimbangkan apakah menyediakan salah satu praktik terbaik ini akan membantu situasi Anda.

  • Frekuensi Spanner menjalankan bentuk operasi baca selama interval adalah contoh yang baik dari metrik yang memerlukan dasar pengukuran untuk memberi tahu Anda apakah pengukuran wajar atau merupakan tanda masalah. Setelah menetapkan dasar pengukuran untuk metrik, Anda akan dapat mendeteksi dan menyelidiki penyebab penyimpangan yang tidak terduga dari perilaku normal.

  • Jika Penggunaan CPU relatif konstan sebagian besar waktu, tetapi tiba-tiba menunjukkan lonjakan yang dapat berkorelasi dengan lonjakan mendadak serupa dalam permintaan pengguna atau perilaku aplikasi, hal ini mungkin merupakan indikasi bahwa semuanya berfungsi seperti yang diharapkan.

  • Coba kueri berikut untuk menemukan bentuk baca teratas yang diberi peringkat berdasarkan jumlah pengeksekusi Spanner untuk setiap bentuk baca:

    SELECT interval_end, read_columns, execution_count
FROM SPANNER_SYS.READ_STATS_TOP_MINUTE
ORDER BY execution_count DESC
LIMIT 10;

  • Jika Anda mencari latensi baca serendah mungkin, terutama saat menggunakan konfigurasi instance multi-region, gunakan baca usang, bukan baca kuat untuk mengurangi atau menghapus komponen latensi baca AVG_LEADER_REFRESH_DELAY_SECONDS.

  • Jika hanya melakukan operasi baca, dan Anda dapat mengekspresikan operasi baca menggunakan satu metode baca, Anda harus menggunakan satu metode baca tersebut. Operasi baca tunggal tidak mengunci, tidak seperti transaksi baca-tulis. Oleh karena itu, Anda harus menggunakan transaksi hanya baca daripada transaksi baca-tulis yang lebih mahal saat tidak menulis data.

Langkah selanjutnya