Memecahkan masalah error batas waktu Spanner terlampaui

Halaman ini memberikan ringkasan tentang error yang melewati batas waktu Spanner: apa yang dimaksud dengan error, alasan terjadinya, 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 ketika error melebihi batas waktu terjadi, serta memberikan panduan tentang cara menyelidiki dan menyelesaikan masalah tersebut.

Filosofi percobaan ulang dan batas waktu Spanner

Filosofi percobaan ulang dan batas waktu Spanner berbeda dengan banyak sistem lainnya. Di Spanner, Anda harus menentukan batas waktu waktu tunggu sebagai durasi maksimum respons akan bermanfaat. Menetapkan batas waktu yang singkat secara artifisial agar segera mencoba kembali operasi yang sama tidak direkomendasikan, karena akan menyebabkan situasi ketika operasi tidak pernah selesai. Dalam konteks ini, strategi dan operasi berikut tidak direkomendasikan karena bersifat kontraproduktif dan menggagalkan perilaku percobaan ulang internal Spanner:

  • Menetapkan tenggat waktu yang terlalu singkat. Artinya, operasi tersebut tidak tahan terhadap peningkatan latensi tail sesekali dan tidak dapat diselesaikan sebelum waktunya habis. Namun, tetapkan batas waktu yang merupakan jangka waktu maksimum untuk manfaat respons tersebut.

  • Menetapkan batas waktu yang terlalu lama, dan membatalkan operasi sebelum batas waktu terlewati. Hal ini menyebabkan percobaan ulang dan pemborosan pekerjaan pada setiap percobaan. Secara gabungan, 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 penegakan batas waktu. Batas waktu memungkinkan aplikasi Anda menentukan berapa lama permintaan akan 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 waktu tunggu default dan kebijakan percobaan ulang yang ditentukan dalam file konfigurasi berikut:

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

Cara menyelidiki dan menyelesaikan error umum melampaui batas waktu

Anda mungkin mengalami DEADLINE_EXCEEDED error untuk jenis masalah berikut:

Masalah API akses data

Instance Spanner harus dikonfigurasi dengan benar 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 karena penggunaan CPU melampaui batas responsif yang direkomendasikan. Anda dapat memeriksa penggunaan CPU Spanner di konsol pemantauan yang disediakan di konsol Google Cloud. Anda juga dapat membuat pemberitahuan berdasarkan pemakaian CPU instance.

Resolusi

Guna mengetahui langkah-langkah untuk mengurangi pemakaian CPU instance, baca mengurangi pemakaian CPU.

Memeriksa perincian latensi menyeluruh dari permintaan

Karena 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 memperoleh perincian latensi, Anda dapat menggunakan metrik untuk mendiagnosis latensi, memahami alasan terjadinya, dan menemukan solusi.

Masalah Data API

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

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 mahal mencakup, tetapi tidak terbatas pada, pemindaian penuh pada tabel besar, cross-join pada beberapa tabel besar, atau eksekusi kueri dengan predikat pada kolom non-kunci (juga pemindaian tabel lengkap).

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

Resolusi

Untuk mengoptimalkan kueri Anda, 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 serta membuat perubahan skema pada database. Praktik terbaik ini dapat membantu mengurangi waktu eksekusi pernyataan, yang berpotensi membantu menghilangkan batas waktu yang melebihi error.

Memeriksa pertentangan kunci

Transaksi Spanner harus memperoleh kunci untuk di-commit. Aplikasi yang berjalan pada throughput tinggi dapat menyebabkan transaksi bersaing untuk resource yang sama, sehingga menyebabkan waktu tunggu yang lebih lama untuk mendapatkan kunci dan memengaruhi performa keseluruhan. Hal ini dapat menyebabkan batas waktu yang terlampaui untuk permintaan baca atau tulis.

Anda dapat menemukan penyebab utama transaksi baca-tulis latensi tinggi dengan menggunakan tabel statistik kunci dan memeriksa 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 kunci menggunakan panduan pemecahan masalah terkait tag transaksi.

Resolusi

Terapkan praktik terbaik ini untuk mengurangi pertentangan kunci. Selain itu, gunakan transaksi hanya baca untuk kasus penggunaan baca biasa guna menghindari konflik kunci dengan penulisan. Penggunaan transaksi baca-tulis harus dicadangkan untuk operasi tulis atau alur kerja baca-tulis campuran. Dengan mengikuti langkah-langkah ini, Anda dapat meningkatkan latensi waktu eksekusi transaksi secara keseluruhan dan mengurangi error saat 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 pembacaan dan penulisan yang dilakukan pada database Anda. Praktik terbaik desain skema dan panduan praktik terbaik SQL harus diikuti, apa pun skemanya. Dengan mengikuti panduan ini, Anda akan menghindari masalah desain skema yang paling umum. Beberapa penyebab lain untuk performa buruk dikaitkan dengan pilihan kunci utama, tata letak tabel (lihat menggunakan tabel yang disisipkan untuk akses lebih cepat), desain skema (lihat mengoptimalkan skema untuk performa), dan performa node yang dikonfigurasi dalam instance Spanner Anda (lihat Ringkasan performa Spanner).

Periksa hotspot

Karena Spanner adalah database terdistribusi, desain skema harus memperhitungkan untuk mencegah hotspot. Misalnya, membuat kolom yang meningkat secara monoton akan membatasi jumlah bagian yang dapat digunakan Spanner untuk mendistribusikan beban kerja secara merata. Bottleneck ini dapat mengakibatkan waktu tunggu. 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 menyelesaikan masalah ini. Desain ulang skema database dan gunakan indeks sisipan untuk menghindari indeks yang dapat menyebabkan hotspotting. Jika mengikuti langkah-langkah ini tidak mengurangi masalah, lihat panduan memilih kunci utama untuk mencegah hotspot. Terakhir, hindari pola traffic yang kurang optimal seperti pembacaan rentang yang luas, 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 dengan beban kerja khusus Anda. Ada baiknya Anda mengamati biaya kueri dan menyesuaikan batas waktu agar sesuai dengan kasus penggunaan tertentu.

Resolusi

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

Masalah Admin API

Permintaan Admin API adalah operasi yang mahal jika dibandingkan dengan permintaan API data. Permintaan admin seperti CreateInstance, CreateDatabase, atau CreateBackups dapat memerlukan waktu beberapa detik sebelum menampilkan respons. Library klien Spanner menetapkan batas waktu selama 60 menit untuk permintaan administrator instance dan database. Hal ini untuk memastikan bahwa 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 telah diupdate dan menggunakan versi terbaru. Jika Anda mengakses Spanner API langsung melalui library klien yang Anda buat, pastikan setelan batas waktu yang ditetapkan tidak lebih agresif daripada setelan default (60 menit) untuk permintaan administrator instance dan database.

Masalah Konsol Google Cloud

Kueri yang dikeluarkan dari halaman Spanner Studio di konsol Google Cloud tidak boleh melebihi lima menit. Jika membuat kueri mahal yang membutuhkan 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 dapat di-roll back jika diperlukan.

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 jika item pekerjaan 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 banyak baris. Kemudian, ubah kueri tersebut untuk mencoba dan 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 habis karena item tugas terlalu besar. Pada contoh sebelumnya, dua rekomendasi berikut mungkin membantu. Pertama-tama, Anda dapat mencoba mengaktifkan layanan acak jika belum diaktifkan. Kedua, Anda dapat mencoba menyesuaikan konfigurasi dalam pembacaan database Anda, seperti maxPartitions dan partitionSizeBytes. Untuk mengetahui informasi selengkapnya, lihat PartitionOptions untuk mencoba mengurangi ukuran item tugas. Contoh cara melakukannya dapat ditemukan di Template Dataflow ini.

Batas waktu tambahan melebihi sumber daya pemecahan masalah

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 yang rendah
  • Latensi permintaan Spanner API yang tinggi, tetapi latensi kuerinya rendah

Anda juga dapat melihat referensi pemecahan masalah berikut: