Memecahkan masalah error batas waktu Spanner terlampaui

Halaman ini memberikan ringkasan tentang error batas waktu Spanner terlampaui: apa itu, penyebabnya, serta cara memecahkan masalah dan 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 terjadinya error batas waktu terlampaui, dan memberikan panduan tentang cara menyelidiki dan menyelesaikan masalah ini.

Filosofi batas waktu dan percobaan ulang Spanner

Filosofi batas waktu dan percobaan ulang Spanner berbeda dengan banyak sistem lainnya. Di Spanner, Anda harus menentukan batas waktu tunggu sebagai jumlah waktu maksimum yang diperlukan untuk mendapatkan respons yang berguna. Menetapkan batas waktu yang terlalu singkat hanya untuk segera mencoba lagi operasi yang sama tidak disarankan, karena hal ini akan menyebabkan situasi di mana operasi tidak pernah selesai. Dalam konteks ini, strategi dan operasi berikut tidak direkomendasikan; strategi dan operasi tersebut tidak produktif dan mengalahkan perilaku coba lagi 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 yang diperlukan agar respons bermanfaat.

  • 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 keseluruhan, 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, unmarshaling, 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 lebih lanjut batas waktu gRPC, lihat gRPC dan Batas Waktu.

Cara menyelidiki dan mengatasi error umum batas waktu terlampaui

Anda mungkin mengalami error DEADLINE_EXCEEDED untuk jenis masalah berikut:

Masalah API akses data

Instance Spanner harus dikonfigurasi dengan tepat untuk workload spesifik 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 pemakaian CPU melampaui batas normal yang direkomendasikan. Anda dapat memeriksa pemanfaatan 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 end-to-end permintaan

Saat permintaan berjalan dari klien ke server Spanner dan kembali, ada beberapa lompatan 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 di 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 solusinya.

Masalah Data API

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

Memeriksa kueri yang mahal

Mencoba menjalankan kueri mahal yang tidak dieksekusi dalam batas waktu tunggu yang dikonfigurasi di library klien dapat menyebabkan error batas waktu terlampaui. Beberapa contoh kueri yang mahal mencakup, tetapi tidak terbatas pada, pemindaian penuh tabel besar, gabungan silang 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, rata-rata byte yang dibaca, rata-rata jumlah baris yang dipindai, dan lainnya. Selain itu, Anda dapat membuat rencana eksekusi kueri untuk memeriksa lebih lanjut cara kueri Anda 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 Anda. Praktik terbaik ini dapat membantu mengurangi waktu eksekusi pernyataan, sehingga berpotensi membantu menghilangkan error batas waktu terlampaui.

Memeriksa pertentangan kunci

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

Anda dapat menemukan penyebab utama transaksi baca-tulis dengan latensi tinggi 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 mana yang terlibat dalam konflik penguncian menggunakan panduan pemecahan masalah dengan tag transaksi.

Resolusi

Terapkan praktik terbaik ini untuk mengurangi persaingan kunci. Selain itu, gunakan transaksi hanya baca untuk kasus penggunaan baca biasa guna menghindari konflik penguncian dengan penulisan. Penggunaan transaksi baca-tulis harus dicadangkan untuk alur kerja tulis atau 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 Anda. Skema yang tidak optimal dapat menyebabkan masalah performa saat menjalankan beberapa kueri. Masalah performa ini dapat mencegah permintaan selesai dalam batas waktu yang dikonfigurasi.

Resolusi

Desain skema yang paling optimal akan bergantung pada pembacaan dan penulisan yang dilakukan ke database Anda. Panduan praktik terbaik desain skema dan praktik terbaik SQL harus diikuti terlepas dari spesifikasi skema. Dengan mengikuti panduan ini, Anda dapat menghindari masalah desain skema yang paling umum. Beberapa penyebab utama lain untuk performa buruk dikaitkan dengan pilihan kunci utama, tata letak tabel (lihat menggunakan tabel yang disisipkan 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 workload secara merata. Hambatan ini dapat menyebabkan waktu tunggu habis. Selain itu, Anda dapat menggunakan Key Visualizer untuk memecahkan masalah performa yang disebabkan oleh hotspot.

Resolusi

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

Memeriksa waktu tunggu yang salah dikonfigurasi

Library klien menyediakan default waktu tunggu yang wajar untuk semua permintaan di Spanner. Namun, konfigurasi default ini mungkin perlu disesuaikan untuk workload spesifik Anda. Sebaiknya amati biaya kueri Anda dan sesuaikan batas waktu agar sesuai dengan kasus penggunaan spesifik 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 tidak disarankan untuk menggunakan 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 hasil. Anda dapat bereksperimen dengan waktu tunggu yang dikonfigurasi lebih lama, tetapi jangan pernah menetapkan waktu tunggu yang lebih singkat daripada waktu sebenarnya yang ingin ditunggu oleh 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 lagi atau gagal.

Resolusi

Jika Anda menggunakan library klien Spanner Google untuk mengakses administrator API, pastikan library klien 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.

Google Cloud masalah konsol

Kueri yang dikeluarkan dari halaman Spanner Studio di 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 terlampaui konsol Google Cloud

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 batas waktu dan batas waktu terlampaui jika item kerja terlalu besar. Jika perlu, Anda dapat menyesuaikan konfigurasi waktu tunggu commit Apache Beam.

Resolusi

Jika terjadi error batas waktu terlampaui pada langkah ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, periksa tabel statistik kueri untuk mengetahui kueri mana yang memindai sejumlah besar 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. Dalam contoh sebelumnya, dua rekomendasi berikut dapat membantu. Pertama, Anda dapat mencoba mengaktifkan layanan pengacakan jika belum diaktifkan. Kedua, Anda dapat mencoba mengubah konfigurasi dalam pembacaan database Anda, seperti maxPartitions dan partitionSizeBytes. Untuk mengetahui informasi selengkapnya, lihat PartitionOptions untuk mencoba mengurangi ukuran item kerja. Contoh cara melakukannya dapat ditemukan di template Dataflow ini.

Referensi pemecahan masalah tambahan untuk error batas waktu terlampaui

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 yang 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: