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:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
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
- Masalah Data API
- Masalah Admin API
- Masalah konsol Google Cloud
- Masalah Dataflow
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:
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:
- Memeriksa latensi di komponen Spanner dengan OpenTelemetry
- Memecahkan masalah regresi performa
- Menganalisis kueri yang berjalan di Spanner untuk membantu mendiagnosis masalah performa