Baca statistik

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 operasi baca memberikan insight tentang cara aplikasi menggunakan database, dan berguna saat menyelidiki masalah performa. Misalnya, Anda dapat memeriksa bentuk baca apa yang berjalan terhadap database, seberapa sering bentuk tersebut dijalankan, dan menjelaskan karakteristik performa bentuk baca tersebut. Anda dapat menggunakan statistik operasi baca untuk database guna mengidentifikasi bentuk operasi baca yang menyebabkan penggunaan CPU yang tinggi. Pada level tinggi, statistik operasi 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 memperhitungkan sebagian besar penggunaan CPU. Metode ini tidak cocok 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 dan beberapa overhead lainnya.

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

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 pembacaan tunggal lainnya yang disediakan Spanner tidak mendukung SPANNER_SYS.

Penggunaan CPU yang dikelompokkan menurut bentuk baca

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

  • SPANNER_SYS.READ_STATS_TOP_MINUTE: Membaca statistik bentuk yang digabungkan pada interval 1 menit.
  • SPANNER_SYS.READ_STATS_TOP_10MINUTE: Membaca statistik bentuk yang digabungkan pada interval 10 menit.
  • SPANNER_SYS.READ_STATS_TOP_HOUR: Membaca statistik bentuk yang digabungkan pada interval 1 jam.

Tabel ini memiliki properti berikut:

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

  • Interval didasarkan pada waktu jam. Interval 1 menit berakhir pada menit, interval 10 menit berakhir setiap 10 menit yang dimulai pada jam, dan interval 1 jam berakhir pada jam. Setelah setiap interval, Spanner akan mengumpulkan data dari semua server, lalu membuat data tersebut tersedia di tabel SPANNER_SYS tidak lama setelahnya.

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

    • 1 menit: 11.58.00–11.58.59
    • 10 menit: 11.40–11.49.59
    • 1 jam: 10.00–10.59.59

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

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

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

Skema tabel

Nama kolom Jenis Deskripsi
INTERVAL_END TIMESTAMP Akhir interval waktu saat eksekusi baca yang disertakan terjadi.
REQUEST_TAG STRING Tag permintaan opsional untuk operasi baca ini. Untuk mengetahui informasi selengkapnya tentang penggunaan tag, lihat Memecahkan 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 pembacaan adalah PARTITIONED_READ atau READ. Operasi baca dengan partitionToken yang diperoleh dari PartitionRead API direpresentasikan oleh jenis baca PARTITIONED_READ dan API pembacaan lainnya oleh READ.
READ_COLUMNS ARRAY<STRING> Kumpulan kolom yang telah dibaca. Data ini diurutkan menurut abjad.
FPRINT INT64 Hash nilai REQUEST_TAG jika ada; Jika tidak, hash nilai READ_COLUMNS.
EXECUTION_COUNT INT64 Berapa kali Spanner mengeksekusi bentuk baca selama interval.
AVG_ROWS FLOAT64 Jumlah rata-rata baris yang ditampilkan oleh pembacaan.
AVG_BYTES FLOAT64 Jumlah rata-rata byte data yang ditampilkan oleh pembacaan, tidak termasuk overhead encoding transmisi.
AVG_CPU_SECONDS FLOAT64 Jumlah rata-rata detik CPU sisi server Spanner yang menjalankan pembacaan, tidak termasuk pengambilan data CPU dan overhead lainnya.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Jumlah detik rata-rata yang dihabiskan untuk menunggu karena terkunci.
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 mengonfirmasi dengan pemimpin Paxos bahwa semua penulisan telah diamati.
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 operasi baca ke transaksi hanya baca.

Contoh kueri

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

Membuat daftar statistik dasar untuk setiap bentuk yang telah dibaca 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

Menampilkan daftar bentuk operasi baca, yang diurutkan berdasarkan total penggunaan CPU tertinggi

Kueri berikut menampilkan bentuk operasi 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 agregat

SPANNER_SYS juga berisi tabel untuk menyimpan statistik operasi baca gabungan yang direkam 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 yang dibaca selama interval 1 jam.

Tabel statistik gabungan memiliki properti berikut:

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

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

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

    • 1 menit: 11.58.00–11.58.59
    • 10 menit: 11.40–11.49.59
    • 1 jam: 10.00–10.59.59

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

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

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

    • Jumlah baris yang ditampilkan
    • Membaca jumlah eksekusi
    • Membaca waktu CPU
    • Penguncian penundaan
    • 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 saat terjadi eksekusi bentuk baca yang disertakan.
EXECUTION_COUNT INT64 Berapa kali Spanner mengeksekusi bentuk baca selama interval.
AVG_ROWS FLOAT64 Jumlah rata-rata baris yang ditampilkan oleh pembacaan.
AVG_BYTES FLOAT64 Jumlah rata-rata byte data yang ditampilkan oleh pembacaan, tidak termasuk overhead encoding transmisi.
AVG_CPU_SECONDS FLOAT64 Jumlah rata-rata detik CPU sisi server Spanner yang menjalankan pembacaan, tidak termasuk pengambilan data CPU dan overhead lainnya.
AVG_LOCKING_DELAY_SECONDS FLOAT64 Jumlah detik rata-rata yang dihabiskan untuk menunggu karena terkunci.
AVG_CLIENT_WAIT_SECONDS FLOAT64 Jumlah rata-rata detik yang dihabiskan untuk menunggu karena throttling.
AVG_LEADER_REFRESH_DELAY_SECONDS FLOAT64 Jumlah rata-rata detik yang dihabiskan untuk mengoordinasikan pembacaan di seluruh instance dalam konfigurasi multi-region.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Frekuensi operasi baca yang 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 mencakup beberapa contoh pernyataan SQL yang mengambil statistik operasi baca gabungan. Anda dapat menjalankan pernyataan SQL ini menggunakan library klien, gcloud spanner, atau Konsol Google Cloud.

Menemukan total penggunaan CPU di semua bentuk operasi baca

Kueri berikut menampilkan jumlah jam CPU yang digunakan oleh bentuk operasi baca dalam satu jam terakhir:

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 jangka 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 pembacaan

Statistik operasi baca Spanner sangat berguna ketika Anda perlu menyelidiki penggunaan CPU yang tinggi di database Spanner atau hanya mencoba memahami bentuk pembacaan dengan CPU yang menggunakan banyak CPU di database Anda. Pemeriksaan bentuk baca yang menggunakan sejumlah besar resource database memberi pengguna Spanner cara potensial untuk mengurangi biaya operasional dan mungkin meningkatkan latensi sistem secara umum. Dengan menggunakan langkah-langkah berikut, kami akan menunjukkan cara menggunakan statistik operasi baca untuk menyelidiki penggunaan CPU yang tinggi dalam database Anda.

Pilih jangka waktu untuk diselidiki

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

Kumpulkan statistik operasi baca untuk jangka waktu yang dipilih

Setelah memilih jangka waktu untuk memulai investigasi, kami akan melihat statistik yang dikumpulkan di tabel READ_STATS_TOTAL_10MINUTE pada sekitar waktu tersebut. Hasil kueri ini dapat memberi kita petunjuk tentang bagaimana CPU dan statistik baca lainnya berubah selama periode waktu tersebut. Kueri berikut menampilkan statistik operasi 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
28-05-2020 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
28-05-2020 17.20.00-07.00 0,0006 13715466 2,6801485272173765e-06
28-05-2020 17.30.00-07.00 0,0007 12861966 4,6859741349028595e-07
28-05-2020 17.40.00-07.00 0,0007 3755954 2,7131391918005383e-06
28-05-2020 17.50.00-07.00 0,0006 4248137 1,4328191393074178e-06
28-05-2020 18.00.00-07.00 0,0006 3986198 2,6973481999639748e-06
28-05-2020 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
28-05-2020 19.10.00-07.00 0,0006 13715466 2,6801485272173765e-06
28-05-2020 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 disorot. interval_end dengan nilai 2020-05-28 19:20:00 memiliki waktu CPU yang lebih tinggi, jadi kita akan memilih interval tersebut untuk diselidiki lebih lanjut di langkah berikutnya.

Menemukan bentuk baca yang menyebabkan penggunaan CPU yang tinggi

Menggali sedikit lebih dalam, sekarang kita membuat kueri tabel READ_STATS_TOP_10MINUTE untuk interval yang dipilih pada langkah sebelumnya. Hasil kueri ini dapat membantu menunjukkan bentuk baca mana yang menyebabkan penggunaan CPU yang 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 kembali dari kueri, menampilkan informasi tentang tiga bentuk baca teratas yang diurutkan berdasarkan avg_cpu_seconds. Perhatikan penggunaan ROUND dalam kueri kita untuk membatasi output avg_cpu_seconds hingga 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 ada baris tertentu atau tidak.

Salah satu alasan tingginya penggunaan CPU adalah karena Anda mulai lebih sering mengeksekusi beberapa bentuk baca (execution_count). Mungkin jumlah rata-rata baris yang ditampilkan oleh pembacaan telah meningkat (avg_rows). Jika tidak ada dari properti bentuk baca tersebut 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

Jika Anda telah melalui langkah-langkah sebelumnya, pertimbangkan apakah memberikan salah satu praktik terbaik ini akan membantu situasi Anda.

  • Frekuensi Spanner menjalankan bentuk pembacaan selama interval adalah contoh bagus dari metrik yang memerlukan dasar pengukuran untuk memberi tahu Anda apakah pengukuran wajar atau pertanda 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 untuk sebagian besar waktu, tetapi tiba-tiba menunjukkan lonjakan yang dapat dikorelasikan dengan lonjakan tiba-tiba yang serupa dalam permintaan pengguna atau perilaku aplikasi, hal ini mungkin merupakan indikasi bahwa semuanya berfungsi seperti yang diharapkan.

  • Coba kueri berikut untuk menemukan bentuk pembacaan teratas yang diurutkan berdasarkan frekuensi Spanner yang dieksekusi untuk setiap bentuk operasi 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 yang serendah mungkin, terutama saat menggunakan konfigurasi instance multi-region, gunakan pembacaan yang sudah tidak berlaku, bukan pembacaan yang kuat untuk mengurangi atau menghapus komponen AVG_LEADER_REFRESH_DELAY_SECONDS dari latensi baca.

  • Jika Anda hanya melakukan pembacaan, dan dapat mengekspresikan aktivitas baca menggunakan metode satu bacaan, Anda harus menggunakan metode satu pembacaan tersebut. Tidak seperti transaksi baca-tulis, bacaan tunggal tidak dikunci, sehingga Anda harus menggunakan transaksi hanya baca daripada transaksi baca-tulis yang lebih mahal saat Anda tidak menulis data.

Langkah selanjutnya