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:
- 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 mengatasi error batas waktu terlampaui yang umum
Anda mungkin mengalami error DEADLINE_EXCEEDED
untuk jenis masalah berikut:
- Masalah Data Access API
- Masalah Data API
- Masalah Admin API
- Masalah konsol Google Cloud
- Masalah dataflow
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:
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:
- Memeriksa latensi dalam komponen Spanner dengan OpenTelemetry
- Memecahkan masalah regresi performa
- Menganalisis kueri yang sedang berjalan di Spanner untuk membantu mendiagnosis masalah performa