Mendiagnosis dan mengatasi kesalahan "Tingkat permintaan terlalu besar" (429)

  • Berlaku untuk: ✅ NoSQL

Pengecualian "Tingkat permintaan terlalu besar", yang juga dikenal sebagai kode kesalahan 429, menunjukkan bahwa permintaan Anda terhadap Azure Cosmos DB sedang dibatasi.

Artikel ini berisi penyebab dan solusi yang diketahui untuk berbagai kesalahan kode status 429 untuk API untuk NoSQL. Jika Anda menggunakan API untuk MongoDB, lihat Memecahkan masalah umum di API untuk MongoDB.

Saat menggunakan throughput yang tersedia, Anda menetapkan throughput yang diukur dalam unit permintaan per detik (RU/s) yang diperlukan untuk beban kerja Anda. Operasi database terhadap layanan seperti baca, tulis, dan kueri menggunakan beberapa jumlah unit permintaan (RU). Pelajari selengkapnya tentang request units.

Dalam detik tertentu, jika operasi menggunakan lebih dari unit permintaan yang disediakan, Azure Cosmos DB mengembalikan pengecualian 429. Setiap detik, jumlah unit permintaan yang tersedia untuk digunakan akan direset.

Sebelum mengambil tindakan untuk mengubah RU/s, penting untuk memahami akar penyebab dari pembatasan laju dan menangani masalah yang mendasarinya.

Tip

Panduan dalam artikel ini berlaku untuk database dan kontainer yang menggunakan throughput yang diprovisikan - baik throughput skala otomatis maupun manual.

Ada berbagai pesan kesalahan yang berhubungan dengan berbagai jenis pengecualian 429:

Tingkat permintaan terlalu besar

Ini adalah skenario yang paling umum. Ini terjadi ketika RU yang dikonsumsi oleh operasi pada data melebihi jumlah RU/dtk yang disediakan. Jika Anda menggunakan throughput manual, ini terjadi ketika Anda mengonsumsi lebih banyak RU/dtk dari throughput manual yang dialokasikan. Jika Anda menggunakan autoscale, ini terjadi ketika Anda mengonsumsi lebih dari RU/s maksimum yang tersedia. Misalnya, jika Anda memiliki sumber daya yang disediakan dengan throughput manual 400 RU/dtk, Anda akan melihat kode status 429 saat Anda menggunakan lebih dari 400 unit permintaan per detik. Jika Anda memiliki sumber daya yang disediakan dengan RU/dtk maks skala otomatis sebesar 4000 RU/dtk (skala antara 400 RU/dtk - 4000 RU/dtk), Anda akan melihat 429 respons saat Anda menggunakan lebih dari 4000 unit permintaan dalam satu detik.

Tip

Semua operasi dibebankan berdasarkan jumlah sumber daya yang mereka konsumsi. Biaya ini diukur dalam unit permintaan. Biaya ini termasuk permintaan yang tidak berhasil diselesaikan karena kesalahan aplikasi seperti 400, 412, dan 449. Saat melihat pembatasan kecepatan atau penggunaan, ada baiknya untuk menyelidiki apakah beberapa pola penggunaan berubah yang dapat mengakibatkan peningkatan operasi ini. Secara khusus, periksa tag 412 atau 449 (konflik aktual).

Untuk informasi selengkapnya tentang throughput yang disediakan, lihat Pengenalan throughput yang disediakan di Azure Cosmos DB.

Langkah 1: Periksa metrik untuk menentukan persentase permintaan dengan kesalahan 429

Melihat pesan kesalahan 429 tidak selalu berarti ada masalah dengan database atau kontainer Anda. Persentase kecil dari respons 429 merupakan hal yang normal baik saat Anda menggunakan throughput manual atau skala otomatis, dan ini adalah tanda bahwa Anda memaksimalkan RU/s yang telah Anda sediakan.

Cara menyelidiki

Tentukan berapa persen permintaan Anda ke database atau kontainer Anda yang menghasilkan 429 respons, dibandingkan dengan jumlah keseluruhan permintaan yang berhasil. Dari akun Azure Cosmos DB Anda, arahkan ke Insights>Permintaan>Jumlah Permintaan berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu.

Secara default, SDK klien Azure Cosmos DB dan alat pengimpor data, seperti Azure Data Factory dam pustaka eksekutor massal, akan secara otomatis mencoba ulang permintaan saat mengalami kesalahan 429. Biasanya percobaan ulang tersebut dilakukan hingga sembilan kali. Akibatnya, meskipun Anda dapat melihat 429 respons dalam metrik, kesalahan ini bahkan mungkin belum dikembalikan ke aplikasi Anda.

Cuplikan layar bagan total Permintaan menurut Kode Status yang menunjukkan jumlah permintaan 429 dan 2xx.

Secara umum, untuk beban kerja produksi, jika Anda melihat antara 1-5% permintaan mendapatkan respons 429, dan latensi end-to-end Anda dapat diterima, ini merupakan tanda yang baik bahwa RU/s sedang dimanfaatkan sepenuhnya. Tidak diperlukan tindakan. Jika tidak, lanjutkan ke langkah pemecahan masalah berikutnya.

Important

Rentang 1-5% ini mengasumsikan bahwa partisi akun Anda didistribusikan secara merata. Jika partisi Anda tidak didistribusikan secara merata, partisi masalah Anda dapat mengembalikan sejumlah besar kesalahan 429 sementara tingkat keseluruhan mungkin rendah.

Jika Anda menggunakan autoscale, dimungkinkan untuk melihat 429 respons pada database atau kontainer Anda, bahkan jika RU/s tidak diskalakan ke RU/s maksimum. Untuk penjelasan, lihat bagian Tingkat permintaan besar dengan skala otomatis.

Salah satu pertanyaan umum yang muncul adalah, "Mengapa saya melihat 429 respons dalam metrik Azure Monitor, tetapi tidak ada dalam pemantauan aplikasi saya sendiri?" Jika Metrik Azure Monitor menunjukkan bahwa Anda memiliki 429 respons, tetapi Anda belum melihat apa pun di aplikasi Anda sendiri, ini karena secara default, SDK automatically retried internally on the 429 responses klien Azure Cosmos DB dan permintaan berhasil dalam percobaan ulang berikutnya. Akibatnya, kode status 429 tidak dikembalikan ke aplikasi. Dalam kasus ini, tingkat keseluruhan respons 429 biasanya minimal dan dapat diabaikan dengan aman, dengan asumsi tingkat keseluruhan antara 1-5% dan latensi ujung ke ujung dapat diterima oleh aplikasi Anda.

Langkah 2: Tentukan apakah ada partisi panas

Partisi panas muncul ketika satu atau beberapa kunci partisi logis mengonsumsi jumlah yang tidak proporsional dari total RU/s akibat volume permintaan yang lebih tinggi. Ini dapat disebabkan oleh desain kunci partisi yang tidak mendistribusikan permintaan secara merata. Ini mengakibatkan banyak permintaan diarahkan ke subset kecil partisi logis (yang menyiratkan partisi fisik) yang menjadi panas. Karena semua data untuk partisi logis berada pada satu partisi fisik dan total RU/dtk didistribusikan secara merata di antara partisi fisik, hal ini dapat menyebabkan partisi panas, yang berujung pada respon 429 dan penggunaan throughput yang tidak efisien.

Berikut adalah beberapa contoh strategi pembuatan partisi yang menyebabkan partisi panas:

  • Anda memiliki kontainer yang menyimpan data perangkat IoT untuk beban kerja write-heavy yang dipartisi oleh date. Semua data untuk satu tanggal berada di partisi logis dan fisik yang sama. Karena semua data yang ditulis setiap hari memiliki tanggal yang sama, ini menghasilkan partisi panas setiap hari.

    • Sebaliknya, untuk skenario ini, kunci partisi seperti id (BAIK GUID atau ID perangkat), atau kunci partisi sintetis yang menggabungkan id dan date, menghasilkan kardinalitas nilai yang lebih tinggi dan distribusi volume permintaan yang lebih baik.

  • Anda memiliki skenario multipenyewa dengan kontainer yang dipartisi oleh tenantId. Jika satu penyewa jauh lebih aktif dibandingkan yang lain, hal itu akan mengakibatkan partisi panas. Misalnya, jika penyewa terbesar memiliki 100.000 pengguna, tetapi sebagian besar penyewa memiliki kurang dari 10 pengguna, Anda akan memiliki partisi panas saat dipartisi oleh tenantID.

    • Untuk skenario sebelumnya, pertimbangkan untuk memiliki kontainer khusus untuk penyewa terbesar, yang dipartisikan berdasarkan properti yang lebih terperinci seperti UserId.

Cara mengidentifikasi partisi panas

Untuk memverifikasi apakah ada partisi panas, buka Insights>Throughput>Konsumsi RU yang Dinormalisasi (%) Berdasarkan PartitionKeyRangeID. Lakukan pemfilteran ke database dan kontainer tertentu.

Setiap PartitionKeyRangeId dipetakan ke satu partisi fisik. Jika ada satu PartitionKeyRangeId yang memiliki konsumsi RU Normalisasi yang jauh lebih tinggi daripada yang lain (misalnya, satu secara konsisten berada di 100%, tetapi yang lain berada di 30% atau kurang), ini bisa menjadi tanda partisi panas. Untuk mempelajari selengkapnya tentang metrik Konsumsi RU/dtk yang Dinormalisasi, lihat Cara memantau RU/dtk yang Dinormalisasi untuk kontainer Azure Cosmos DB atau akun.

Cuplikan layar yang memperlihatkan bagan Konsumsi RU yang Dinormalisasi oleh PartitionKeyRangeId dengan partisi panas.

Untuk melihat kunci partisi logis mana yang paling banyak menggunakan RU/s, gunakan Log Diagnostik Azure. Kueri sampel ini menjumlah total unit permintaan yang dikonsumsi per detik pada setiap kunci partisi logis.

Important

Pengaktifan log diagnostik menimbulkan biaya terpisah untuk layanan Analitik Log, yang ditagih berdasarkan volume data yang diserap. Sebaiknya Anda mengaktifkan log diagnostik untuk waktu yang terbatas saat melakukan debug, dan menonaktifkannya saat tidak lagi diperlukan. Untuk mempelajari selengkapnya, lihatHarga Azure Monitor.

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Output sampel ini menunjukkan bahwa dalam satu menit tertentu, kunci partisi logis dengan nilai Contoso mengonsumsi sekitar 12.000 RU/dtk, sedangkan kunci partisi logis dengan nilai Fabrikam mengonsumsi kurang dari 600 RU/dtk. Jika pola ini konsisten selama periode waktu saat pembatasan terjadi, pola ini akan menunjukkan adanya partisi panas.

Cuplikan layar hasil yang menunjukkan kunci partisi logis yang menggunakan unit permintaan terbanyak per detik.

Tip

Dalam beban kerja apa pun, ada variasi alami dalam volume permintaan di seluruh partisi logis. Anda harus menentukan apakah partisi panas disebabkan oleh kecondongan mendasar karena pemilihan kunci partisi (yang mungkin memerlukan pengubahan kunci) atau lonjakan sementara karena variasi alami dalam pola beban kerja.

Baca panduan tentang cara memilih kunci partisi yang baik.

Jika ada persentase tinggi dari permintaan yang jumlahnya dibatasi dan tidak ada partisi panas:

Jika ada persentase tinggi dari permintaan yang jumlahnya dibatasi dan ada partisi panas yang mendasarinya:

  • Jangka panjang, untuk biaya dan performa terbaik, pertimbangkan untuk mengubah kunci partisi. Kunci partisi tidak dapat diperbarui, sehingga ini diperlukan migrasi data ke kontainer baru dengan kunci partisi yang berbeda. Azure Cosmos DB mendukung alat migrasi data langsung untuk tujuan ini.
  • Dalam jangka pendek, Anda dapat meningkatkan RU/s sumber daya secara keseluruhan untuk memungkinkan throughput yang lebih besar ke partisi panas. Hal ini tidak disarankan sebagai strategi jangka panjang karena akan menyebabkan kelebihan provisi RU/s dan biaya yang lebih tinggi.
  • Jangka pendek, Anda dapat mendistribusikan ulang throughput di seluruh partisi (pratinjau) untuk menetapkan lebih banyak RU ke partisi fisik yang panas. Ini disarankan hanya ketika partisi fisik panas dapat diprediksi dan konsisten.

Tip

Ketika Anda meningkatkan throughput, operasi peningkatan skala selesai secara instan atau memerlukan waktu hingga 5-6 jam, tergantung pada jumlah RU/s yang ingin Anda capai. Jika Anda ingin mengetahui jumlah RU/dtk tertinggi yang dapat Anda atur tanpa memicu operasi peningkatan skala asinkron (yang mengharuskan Azure Cosmos DB untuk menyediakan lebih banyak partisi fisik), kalikan jumlah PartitionKeyRangeIds yang berbeda dengan 10.0000 RU/dtk. Misalnya, jika Anda memiliki 30.000 RU/dtk yang disediakan dan lima partisi fisik (6000 RU/dtk yang dialokasikan per partisi fisik), Anda dapat meningkat menjadi 50.000 RU/dtk (10.000 RU/dtk per partisi fisik) dalam operasi peningkatan skala seketika. Peningkatan menjadi >50.000 RU/s akan membutuhkan operasi peningkatan asinkron. Untuk mempelajari lebih lanjut, lihat Praktik terbaik untuk menskalakan throughput yang disediakan (RU/s).

Langkah 3: Tentukan permintaan apa yang mengembalikan 429 respons

Cara menyelidiki permintaan dengan 429 respons

Gunakan Log Diagnostik Azure untuk mengidentifikasi permintaan mana yang mengembalikan 429 respons dan berapa banyak RU yang mereka konsumsi. Sampel kueri ini diagregasi pada tingkat menit.

Important

Pengaktifan log diagnostik menimbulkan biaya terpisah untuk layanan Analitik Log yang ditagih berdasarkan volume data yang diserap. Sebaiknya Anda mengaktifkan log diagnostik untuk waktu yang terbatas saat melakukan debug, dan menonaktifkannya saat tidak lagi diperlukan. Untuk mempelajari selengkapnya, lihatHarga Azure Monitor.

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Misalnya, output sampel ini menunjukkan bahwa setiap menit, 30% permintaan Buat Dokumen dibatasi lajunya, dengan setiap permintaan menggunakan rata-rata 17 RU.

Cuplikan layar yang memperlihatkan permintaan dengan kode status 429 di Log Diagnostik.

Menggunakan perencana kapasitas Azure Cosmos DB

Anda dapat memanfaatkan perencana kapasitas Azure Cosmos DB untuk memahami throughput yang diprovisikan mana yang paling cocok berdasarkan beban kerja Anda (volume dan jenis operasi serta ukuran dokumen). Anda dapat menyesuaikan perhitungan lebih lanjut dengan menyediakan data sampel untuk mendapatkan estimasi yang lebih akurat.

Respons 429 pada permintaan pembuatan, penggantian, atau upsert dokumen

Secara default, dalam API untuk NoSQL, semua properti diindeks secara default. Setel kebijakan pengindeksan agar hanya mengindeks properti yang diperlukan. Ini mengurangi RU yang diperlukan per operasi pembuatan dokumen, yang mengurangi kemungkinan mendapatkan respons 429 atau memungkinkan Anda mencapai operasi lebih banyak per detik dengan jumlah RU/dtk yang sama.

429 tanggapan terhadap permintaan dokumen kueri

Ikuti panduan untuk mengatasi masalah kueri dengan biaya RU tinggi.

429 respons tentang menjalankan prosedur tersimpan

Prosedur tersimpan ditujukan untuk operasi yang memerlukan transaksi tulis di seluruh nilai kunci partisi. Tidak disarankan untuk menggunakan prosedur tersimpan untuk operasi baca atau kueri dalam jumlah besar. Untuk performa terbaik, operasi baca atau kueri ini harus dilakukan di sisi klien, menggunakan Azure Cosmos DB SDK.

Tingkat permintaan besar dengan skala otomatis

Semua panduan dalam artikel ini berlaku untuk throughput manual dan skala otomatis.

Saat menggunakan skala otomatis, pertanyaan umum yang muncul adalah "Apakah masih mungkin untuk melihat 429 respons dengan skala otomatis?"

Jawabannya adalah ya. Ada dua skenario utama di mana hal ini dapat terjadi:

Skenario 1: Ketika RU/dtk yang dikonsumsi secara keseluruhan melebihi RU/dtk maksimum database atau kontainer, layanan membatasi permintaan yang sesuai. Hal ini sama seperti melebihi alokasi throughput manual dari database atau kontainer secara keseluruhan.

Skenario 2: Jika ada "hot partition", yaitu, nilai kunci partisi logis yang memiliki jumlah permintaan yang jauh lebih tinggi dibandingkan dengan nilai kunci partisi lainnya, dimungkinkan bagi partisi fisik yang mendasarinya melebihi batas RU/dtk. Sebagai praktik terbaik, untuk menghindari partisi panas, pilih kunci partisi yang baik yang menghasilkan distribusi yang seimbang pada penyimpanan dan throughput. Ini mirip dengan ketika ada partisi panas saat menggunakan throughput manual.

Misalnya, jika Anda memilih opsi throughput 20.000 RU/s maksimum dan memiliki penyimpanan 200 GB, dengan empat partisi fisik, setiap partisi fisik dapat diskalakan secara otomatis hingga 5.000 RU/s. Jika terdapat hot partition pada logical partition key tertentu, Anda akan melihat respons 429 ketika physical partition yang mendasarinya melampaui 5000 RU/dtk, yaitu, melampaui 100% pemanfaatan yang dinormalisasi.

Ikuti panduan di Langkah 1, Langkah 2, dan Langkah 3 untuk men-debug skenario ini.

Pertanyaan umum lain yang muncul adalah, Mengapa konsumsi RU yang dinormalisasinya 100%, tetapi skala otomatis tidak diskalakan ke RU/s maksimumnya?

Ini biasanya terjadi untuk beban kerja yang memiliki lonjakan penggunaan sementara atau lonjakan yang terputus-putus. Saat Anda menggunakan skala otomatis, Azure Cosmos DB hanya menskalakan RU/s ke throughput maksimum ketika konsumsi RU yang dinormalisasi adalah 100% untuk periode waktu yang berkelanjutan dalam interval 5 detik. Hal ini dilakukan untuk memastikan logika penskalaan hemat bagi pengguna, karena memastikan bahwa lonjakan tunggal dan sesaat tidak menyebabkan penskalaan yang tidak diperlukan dan biaya yang lebih tinggi. Ketika ada lonjakan sementara, sistem biasanya menskalakan hingga melewati nilai RU/s yang sebelumnya, tetapi tetap lebih rendah dari RU/s maksimum. Untuk mempelajari lebih lanjut, lihat Konsumsi RU yang dinormalisasi dan skala otomatis.

Pembatasan laju pada permintaan metadata

Pembatasan laju metadata dapat terjadi saat Anda melakukan operasi metadata dalam volume tinggi pada database dan/atau kontainer. Operasi metadata antara lain:

  • Membuat, membaca, memperbarui, atau menghapus kontainer atau database
  • Mencantumkan database atau kontainer di akun Azure Cosmos DB
  • Kueri penawaran untuk memeriksa throughput yang telah dialokasikan saat ini

Ada batas RU yang dicadangkan sistem untuk operasi ini, jadi meningkatkan RU/s database atau kontainer yang disediakan tidak berpengaruh dan tidak disarankan. Lihat Batas Layanan Control Plane.

Cara menyelidiki

Masuk ke Insights>Sistem>Permintaan Metadata Berdasarkan Kode Status. Lakukan pemfilteran ke database dan kontainer tertentu jika diinginkan.

Cuplikan layar permintaan metadata menurut bagan kode status di Insights.

  • Jika aplikasi Anda perlu melakukan operasi metadata, pertimbangkan untuk menerapkan kebijakan backoff untuk mengirim permintaan ini dalam jumlah yang lebih rendah.

  • Gunakan instans klien Azure Cosmos DB statis. Ketika DocumentClient atau CosmosClient diinisialisasi, Azure Cosmos DB SDK mengambil metadata tentang akun, termasuk informasi tentang tingkat konsistensi, database, kontainer, partisi, dan penawaran. Inisialisasi ini mungkin mengonsumsi sejumlah besar RU, dan jarang harus dilakukan. Gunakan satu instans DocumentClient dan gunakan untuk masa pakai aplikasi Anda.

  • Simpan nama database dan kontainer di cache. Ambil nama database dan kontainer Anda dari konfigurasi atau simpan nama tersebut di cache saat memulai. Panggilan seperti ReadDatabaseAsync/ReadDocumentCollectionAsync atau CreateDatabaseQuery/CreateDocumentCollectionQuery akan menghasilkan panggilan metadata ke layanan, yang mengonsumsi dari batas RU yang dicadangkan oleh sistem. Operasi ini tidak boleh dilakukan terlalu sering.

Pembatasan laju karena kesalahan layanan sementara

Kesalahan 429 ini dihasilkan ketika permintaan menemui kesalahan layanan sementara. Meningkatkan RU pada database atau kontainer tidak berpengaruh dan tidak disarankan.

Ulangi permintaan tersebut. Jika kesalahan berlanjut selama beberapa menit, ajukan tiket dukungan dari portal Microsoft Azure.

Langkah berikutnya

  • Last updated on