Memecahkan masalah error batas waktu Spanner terlampaui

Halaman ini memberikan ringkasan tentang error batas waktu Spanner terlampaui: pengertiannya, penyebabnya, dan cara memecahkan masalah serta mengatasinya.

Saat mengakses Spanner API, permintaan mungkin gagal karena error DEADLINE_EXCEEDED. Error ini menunjukkan bahwa respons belum diterima dalam periode waktu tunggu yang dikonfigurasi.

Error batas waktu terlampaui dapat terjadi karena berbagai alasan, seperti instance Spanner yang kelebihan beban, skema yang tidak dioptimalkan, atau kueri yang tidak dioptimalkan. Halaman ini menjelaskan skenario umum saat error batas waktu terlampaui terjadi, dan memberikan panduan tentang cara menyelidiki dan menyelesaikan masalah ini.

Batas waktu dan filosofi percobaan ulang Spanner

Filosofi batas waktu dan percobaan ulang Spanner berbeda dengan banyak sistem lainnya. Di Spanner, Anda harus menentukan batas waktu waktu tunggu sebagai jumlah waktu maksimum saat respons berguna. Menetapkan batas waktu yang singkat secara artifisial hanya untuk segera mencoba kembali operasi yang sama tidak direkomendasikan, karena hal ini akan menyebabkan situasi saat operasi tidak pernah selesai. Dalam konteks ini, strategi dan operasi berikut tidak direkomendasikan; strategi dan operasi tersebut tidak produktif dan mengalahkan perilaku percobaan ulang internal Spanner:

  • Menetapkan batas waktu yang terlalu singkat. Artinya, operasi tidak tahan terhadap peningkatan latensi ekor sesekali dan tidak dapat diselesaikan sebelum waktu tunggu habis. Sebagai gantinya, tetapkan batas waktu yang merupakan jumlah waktu maksimum saat respons berguna.

  • Menetapkan batas waktu yang terlalu lama, dan membatalkan operasi sebelum batas waktu terlampaui. Hal ini menyebabkan percobaan ulang dan pekerjaan yang sia-sia pada setiap percobaan. Secara agregat, hal ini dapat menimbulkan beban tambahan yang signifikan pada instance Anda.

Apa yang dimaksud dengan error batas waktu terlampaui?

Saat Anda menggunakan salah satu library klien Spanner, lapisan gRPC yang mendasarinya akan menangani komunikasi, marshaling, unmarshalling, dan penerapan batas waktu. Batas waktu memungkinkan aplikasi Anda menentukan berapa lama aplikasi bersedia menunggu permintaan selesai sebelum permintaan dihentikan dengan error batas waktu terlampaui.

Panduan konfigurasi waktu tunggu menunjukkan cara menentukan batas waktu (atau waktu tunggu) di setiap library klien Spanner yang didukung. Library klien Spanner menggunakan setelan kebijakan percobaan ulang dan waktu tunggu default yang ditentukan dalam file konfigurasi berikut:

Untuk mempelajari batas waktu gRPC lebih lanjut, lihat gRPC dan Batas Waktu.

Cara menyelidiki dan mengatasi error batas waktu terlampaui yang umum

Anda mungkin mengalami error DEADLINE_EXCEEDED untuk jenis masalah berikut:

Masalah Data access API

Instance Spanner harus dikonfigurasi dengan tepat untuk workload tertentu Anda guna menghindari masalah API akses data. Bagian berikut menjelaskan cara menyelidiki dan menyelesaikan berbagai masalah API akses data.

Memeriksa beban CPU instance Spanner

Latensi permintaan dapat meningkat secara signifikan saat penggunaan CPU melampaui nilai minimum yang sehat yang direkomendasikan. Anda dapat memeriksa penggunaan CPU Spanner di konsol pemantauan yang disediakan di konsol Google Cloud. Anda juga dapat membuat pemberitahuan berdasarkan penggunaan CPU instance.

Resolusi

Untuk mengetahui langkah-langkah mengurangi penggunaan CPU instance, lihat mengurangi penggunaan CPU.

Memeriksa perincian latensi menyeluruh permintaan

Saat permintaan berpindah dari klien ke server Spanner dan kembali, ada beberapa hop jaringan yang perlu dilakukan: dari library klien ke Google Front End (GFE); dari GFE ke frontend Spanner API; dan terakhir dari frontend Spanner API ke database Spanner. Jika ada masalah jaringan pada salah satu tahap ini, Anda mungkin melihat error batas waktu terlampaui.

Anda dapat merekam latensi di setiap tahap. Untuk mempelajari lebih lanjut, lihat Titik latensi dalam permintaan Spanner. Untuk menemukan tempat terjadinya latensi di Spanner, lihat mengidentifikasi tempat terjadinya latensi di Spanner.

Resolusi

Setelah mendapatkan perincian latensi, Anda dapat menggunakan metrik untuk mendiagnosis latensi, memahami penyebabnya, dan menemukan solusi.

Masalah Data API

Pola penggunaan Data API Spanner tertentu yang tidak optimal dapat menyebabkan error batas waktu terlampaui. Bagian ini berisi panduan cara memeriksa pola penggunaan yang tidak optimal ini.

Memeriksa kueri yang mahal

Mencoba menjalankan kueri mahal yang tidak dieksekusi dalam batas waktu waktu tunggu yang dikonfigurasi di library klien dapat mengakibatkan error batas waktu terlampaui. Beberapa contoh kueri yang mahal mencakup, tetapi tidak terbatas pada, pemindaian penuh tabel besar, cross-join di beberapa tabel besar, atau eksekusi kueri dengan predikat di kolom non-kunci (juga pemindaian tabel penuh).

Anda dapat memeriksa kueri yang mahal menggunakan tabel statistik kueri dan tabel statistik transaksi. Tabel ini menampilkan informasi tentang kueri dan transaksi yang berjalan lambat, seperti jumlah rata-rata baris yang dibaca, byte rata-rata yang dibaca, jumlah rata-rata baris yang dipindai, dan lainnya. Selain itu, Anda dapat membuat rencana eksekusi kueri untuk lebih memeriksa cara kueri dieksekusi.

Resolusi

Untuk mengoptimalkan kueri, gunakan panduan praktik terbaik untuk kueri SQL. Anda juga dapat menggunakan data yang diperoleh melalui tabel statistik yang disebutkan sebelumnya dan rencana eksekusi untuk mengoptimalkan kueri dan membuat perubahan skema pada database. Praktik terbaik ini dapat membantu mengurangi waktu eksekusi pernyataan, yang berpotensi membantu menghilangkan error batas waktu terlampaui.

Memeriksa pertentangan kunci

Transaksi Spanner perlu memperoleh kunci untuk melakukan commit. Aplikasi yang berjalan dengan throughput tinggi dapat menyebabkan transaksi bersaing untuk mendapatkan resource yang sama, sehingga meningkatkan waktu tunggu untuk mendapatkan kunci dan memengaruhi performa secara keseluruhan. Hal ini dapat menyebabkan batas waktu terlampaui untuk permintaan baca atau tulis.

Anda dapat menemukan akar masalah untuk transaksi baca-tulis latensi tinggi dengan menggunakan tabel statistik kunci dan membaca postingan blog berikut. Dalam tabel statistik kunci, Anda dapat menemukan kunci baris dengan waktu tunggu kunci tertinggi.

Panduan pemecahan masalah konflik kunci ini menjelaskan cara menemukan transaksi yang mengakses kolom yang terlibat dalam konflik kunci. Anda juga dapat menemukan transaksi yang terlibat dalam konflik kunci menggunakan panduan pemecahan masalah dengan tag transaksi.

Resolusi

Terapkan praktik terbaik ini untuk mengurangi pertentangan kunci. Selain itu, gunakan transaksi hanya baca untuk kasus penggunaan pembacaan biasa guna menghindari konflik kunci dengan operasi tulis. Penggunaan transaksi baca-tulis harus dicadangkan untuk menulis atau alur kerja baca-tulis campuran. Mengikuti langkah-langkah ini akan meningkatkan latensi keseluruhan waktu eksekusi transaksi dan mengurangi error batas waktu terlampaui.

Memeriksa skema yang tidak dioptimalkan

Sebelum mendesain skema database yang optimal untuk database Spanner, Anda harus mempertimbangkan jenis kueri yang akan dijalankan di database. Skema yang kurang optimal dapat menyebabkan masalah performa saat menjalankan beberapa kueri. Masalah performa ini dapat mencegah permintaan diselesaikan dalam batas waktu yang dikonfigurasi.

Resolusi

Desain skema yang paling optimal akan bergantung pada operasi baca dan tulis yang dilakukan ke database Anda. Panduan praktik terbaik desain skema dan praktik terbaik SQL harus diikuti, terlepas dari detail skema. Dengan mengikuti panduan ini, Anda akan menghindari masalah desain skema yang paling umum. Beberapa akar penyebab lain untuk performa yang buruk diatribusikan ke pilihan kunci utama, tata letak tabel (lihat menggunakan tabel yang diselingi untuk akses yang lebih cepat), desain skema (lihat mengoptimalkan skema untuk performa), dan performa node yang dikonfigurasi dalam instance Spanner Anda (lihat Ringkasan performa Spanner).

Memeriksa hotspot

Karena Spanner adalah database terdistribusi, desain skema harus memperhitungkan pencegahan hotspot. Misalnya, membuat kolom yang meningkat secara monoton akan membatasi jumlah pemisahan yang dapat digunakan Spanner untuk mendistribusikan beban kerja secara merata. Bottleneck ini dapat menyebabkan waktu tunggu habis. Selain itu, Anda dapat menggunakan Key Visualizer untuk memecahkan masalah performa yang disebabkan oleh hotspot.

Resolusi

Lihat resolusi yang diidentifikasi di bagian sebelumnya Memeriksa skema yang tidak dioptimalkan sebagai langkah pertama untuk mengatasi masalah ini. Desain ulang skema database dan gunakan indeks interleaved untuk menghindari indeks yang dapat menyebabkan hotspot. Jika mengikuti langkah-langkah ini tidak memitigasi masalah, lihat panduan memilih kunci utama untuk mencegah hotspot. Terakhir, hindari pola traffic yang kurang optimal seperti pembacaan rentang besar yang mungkin mencegah pemisahan berbasis beban.

Memeriksa waktu tunggu yang salah dikonfigurasi

Library klien memberikan waktu tunggu default yang wajar untuk semua permintaan di Spanner. Namun, konfigurasi default ini mungkin perlu disesuaikan untuk workload tertentu. Sebaiknya amati biaya kueri Anda dan sesuaikan batas waktu agar sesuai dengan kasus penggunaan tertentu Anda.

Resolusi

Setelan default untuk waktu tunggu cocok untuk sebagian besar kasus penggunaan. Pengguna dapat mengganti konfigurasi ini (lihat panduan waktu tunggu dan percobaan ulang kustom), tetapi sebaiknya jangan gunakan waktu tunggu yang lebih agresif daripada waktu tunggu default. Jika Anda memutuskan untuk mengubah waktu tunggu, tetapkan ke jumlah waktu sebenarnya yang bersedia ditunggu aplikasi untuk mendapatkan hasilnya. Anda dapat bereksperimen dengan waktu tunggu yang dikonfigurasi lebih lama, tetapi jangan pernah menetapkan waktu tunggu yang lebih singkat dari waktu yang sebenarnya bersedia ditunggu aplikasi, karena hal ini akan menyebabkan operasi dicoba ulang lebih sering.

Masalah Admin API

Permintaan Admin API adalah operasi yang mahal jika dibandingkan dengan permintaan data API. Permintaan admin seperti CreateInstance, CreateDatabase, atau CreateBackups dapat memerlukan waktu beberapa detik sebelum menampilkan respons. Library klien Spanner menetapkan batas waktu 60 menit untuk permintaan administrator instance dan database. Hal ini untuk memastikan server memiliki kesempatan untuk menyelesaikan permintaan sebelum klien mencoba ulang atau gagal.

Resolusi

Jika Anda menggunakan library klien Spanner Google untuk mengakses API administrator, pastikan library klien telah diupdate dan menggunakan versi terbaru. Jika Anda mengakses Spanner API secara langsung melalui library klien yang Anda buat, pastikan Anda tidak memiliki setelan batas waktu yang lebih agresif daripada setelan default (60 menit) untuk permintaan administrator instance dan database.

Masalah Konsol Google Cloud

Kueri yang dikeluarkan dari halaman Spanner Studio konsol Google Cloud tidak boleh melebihi lima menit. Jika membuat kueri mahal yang memerlukan waktu lebih dari lima menit untuk dijalankan, Anda akan melihat pesan error berikut:

Screenshot pesan error batas waktu Konsol Google Cloud terlampaui

Backend akan membatalkan kueri yang gagal, dan transaksi mungkin di-roll back jika perlu.

Resolusi

Anda dapat menulis ulang kueri menggunakan panduan praktik terbaik untuk kueri SQL.

Masalah Dataflow

Di Apache Beam, konfigurasi waktu tunggu default adalah dua jam untuk operasi baca dan 15 detik untuk operasi commit. Konfigurasi ini memungkinkan operasi yang lebih lama jika dibandingkan dengan waktu tunggu batas waktu library klien mandiri. Namun, Anda masih dapat menerima error waktu tunggu habis dan batas waktu terlampaui saat item pekerjaan terlalu besar. Jika perlu, Anda dapat menyesuaikan konfigurasi waktu tunggu commit Apache Beam.

Resolusi

Jika error batas waktu terlampaui terjadi pada langkah ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, periksa tabel statistik kueri untuk mengetahui kueri mana yang memindai banyak baris. Kemudian, ubah kueri tersebut untuk mencoba mengurangi waktu eksekusi.

Contoh lain error batas waktu Dataflow terlampaui ditampilkan dalam pesan pengecualian berikut:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Waktu tunggu ini terjadi karena item pekerjaan terlalu besar. Pada contoh sebelumnya, dua rekomendasi berikut mungkin dapat membantu. Pertama, Anda dapat mencoba mengaktifkan layanan shuffle jika belum diaktifkan. Kedua, Anda dapat mencoba menyesuaikan konfigurasi dalam pembacaan database, seperti maxPartitions dan partitionSizeBytes. Untuk mengetahui informasi selengkapnya, lihat PartitionOptions untuk mencoba mengurangi ukuran item pekerjaan. Contoh cara melakukannya dapat ditemukan dalam Template Dataflow ini.

Referensi pemecahan masalah batas waktu terlampaui tambahan

Jika Anda masih melihat error DEADLINE_EXCEEDED setelah menyelesaikan langkah-langkah pemecahan masalah, buka kasus dukungan jika Anda mengalami skenario berikut:

  • Latensi Google Front End tinggi, tetapi latensi permintaan Spanner API rendah
  • Latensi permintaan Spanner API yang tinggi, tetapi latensi kueri yang rendah

Anda juga dapat melihat referensi pemecahan masalah berikut: