Bagikan melalui

Mendiagnosis dan memecahkan masalah pengecualian waktu tunggu permintaan di Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: NoSQL

Kesalahan HTTP 408 terjadi jika SDK tidak dapat menyelesaikan permintaan sebelum batas waktu terjadi.

Penting untuk memastikan desain aplikasi mematuhi panduan untuk merancang aplikasi tangguh dengan SDK Azure Cosmos DB untuk memastikannya bereaksi dengan benar terhadap kondisi jaringan yang berbeda. Aplikasi Anda harus memiliki percobaan ulang untuk kesalahan waktu habis karena ini biasanya diharapkan dalam sistem terdistribusi.

Saat mengevaluasi kasus kesalahan waktu habis:

  • Apa dampak yang diukur dalam volume operasi yang terpengaruh dibandingkan dengan operasi yang berhasil? Apakah itu ada dalam SLA layanan?
  • Apakah latensi/ketersediaan P99 terpengaruh?
  • Apakah kegagalan memengaruhi semua instans aplikasi Anda atau hanya sebagian? Ketika masalah direduksi menjadi subset instans, biasanya masalah itu terkait dengan instans tersebut.

Menyesuaikan batas waktu pada SDK .NET Azure Cosmos DB

SDK memiliki dua alternatif berbeda untuk mengontrol batas waktu, masing-masing dengan lingkup yang berbeda.

Batas waktu tingkat permintaan

Konfigurasi CosmosClientOptions.RequestTimeout (atau ConnectionPolicy.RequestTimeout untuk SDK v2) memungkinkan Anda mengatur batas waktu untuk permintaan jaringan setelah permintaan meninggalkan SDK dan berada di jaringan, hingga respons diterima.

Konfigurasi CosmosClientOptions.OpenTcpConnectionTimeout (atau ConnectionPolicy.OpenTcpConnectionTimeout untuk SDK v2) memungkinkan Anda mengatur batas waktu untuk waktu yang dihabiskan untuk membuka koneksi awal. Setelah koneksi dibuka, permintaan berikutnya akan menggunakan koneksi.

Operasi yang dimulai oleh pengguna dapat mencakup beberapa permintaan jaringan, misalnya, mencoba kembali. Kedua konfigurasi ini adalah per permintaan, bukan end-to-end untuk operasi.

TokenPembatalan

Semua operasi asinkron di SDK memiliki parameter pilihan TokenPembatalan. Parameter CancellationToken ini digunakan di seluruh operasi, di semua permintaan jaringan dan percobaan ulang. Di sela-sela permintaan jaringan, token pembatalan dapat diperiksa dan operasi dibatalkan jika token terkait telah kedaluwarsa. Token pembatalan harus digunakan untuk menentukan perkiraan waktu habis yang diharapkan pada lingkup operasi.

Catatan

Parameter CancellationToken adalah mekanisme di mana pustaka akan memeriksa pembatalan jika hal itu tidak menyebabkan keadaan tidak valid. Operasi ini mungkin tidak membatalkan dengan tepat kapan waktu yang ditentukan dalam pembatalan sudah habis. Sebaliknya, operasi akan dibatalkan setelah waktunya habis dan dirasa aman.

Langkah-langkah pemecahan masalah

Daftar berikut ini berisi penyebab dan solusi yang diketahui untuk pengecualian waktu tunggu permintaan.

CosmosOperationCanceledException

Jenis pengecualian ini kerap muncul ketika aplikasi Anda meneruskan CancellationTokens ke operasi SDK. SDK memeriksa status CancellationTokencoba lagi di sela-sela proses tersebut, dan jika CancellationToken dibatalkan, SDK akan membatalkan operasi saat ini dengan pengecualian ini.

Pengecualian Message / ToString() juga akan menunjukkan status CancellationToken Anda melalui Cancellation Token has expired: true dan juga akan berisi Diagnostik yang berisi konteks pembatalan permintaan yang sedang diproses.

Pengecualian ini sifatnya aman dan Anda dapat mencoba kembali, serta dapat diperlakukan sebagai batas waktu dari perspektif percobaan kembali.

Solusi

Verifikasi waktu yang dikonfigurasi di CancellationToken Anda, pastikan waktunya lebih besar dari RequestTimeout dan CosmosClientOptions.OpenTcpConnectionTimeout (jika Anda menggunakan mode Langsung). Jika waktu yang tersedia di CancellationToken kurang dari waktu habis yang dikonfigurasi, dan SDK mengalami masalah konektivitas yang bersifat sementara, SDK tidak akan dapat mencoba ulang dan akan memunculkan CosmosOperationCanceledException.

Pemanfaatan CPU tinggi

Penggunaan CPU tinggi adalah kasus yang paling umum. Agar latensi optimal, penggunaan CPU harus sekitar 40 persen. Gunakan 10 detik sebagai interval untuk memantau penggunaan maksimum (bukan rata-rata) CPU. Lonjakan CPU lebih umum terjadi pada kueri lintas-partisi yang mungkin melakukan banyak koneksi untuk satu kueri.

Waktu habis akan berisi Diagnostik, yang berisi:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Jika nilai cpu melebihi 70%, waktu habis kemungkinan disebabkan oleh habisnya CPU. Dalam hal ini, solusinya adalah menyelidiki sumber pemanfaatan CPU yang tinggi dan menguranginya, atau menskalakan mesin ke ukuran sumber daya yang lebih besar.
  • Apabila node threadInfo/isThreadStarving memiliki nilai True, penyebabnya adalah habisnya alur. Solusi untuk hal ini adalah menyelidiki sumber dari kekurangan utas (utas yang berpotensi terkunci), atau memperbesar skala ukuran sumber daya komputer.
  • Jika waktu dateUtc di antara pengukuran tidak berada di kisaran 10 detik, artinya ini juga akan menunjukkan adanya ketidaksesuaian pada kumpulan rangkaian. CPU diukur sebagai Tugas independen yang diantrekan dalam kumpulan rangkaian setiap 10 detik, sehingga jika waktu di antara setiap pengukurannya lebih lama, artinya Tugas asinkron tidak bisa diproses secara tepat waktu. Skenario-skenario paling umum adalah saat memblokir panggilan melalui kode asinkronisasi dalam kode aplikasi.

Solusi

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Ketersediaan soket atau port mungkin rendah

Saat berjalan di Azure, klien yang menggunakan SDK .NET dapat kehabisan port Azure SNAT (PAT).

Solusi 1

Jika Anda menjalankan Azure VM, ikuti panduan kehabisan port SNAT.

Solusi 2

Jika Anda menjalankan Azure App Service, ikuti panduan pemecahan masalah kesalahan koneksi dan menggunakan diagnostik Azure App Service.

Solusi 3

Jika Anda menjalankan Azure Functions, pastikan Anda mengikuti rekomendasi Azure Functions untuk mempertahankan klien database tunggal atau statis untuk semua layanan yang terlibat (termasuk Azure Cosmos DB). Periksa batas layanan berdasarkan jenis dan ukuran hosting Aplikasi Fungsi Anda.

Solusi 4

Jika Anda menggunakan proksi HTTP, pastikan proksi tersebut dapat mendukung jumlah koneksi yang dikonfigurasi di SDK ConnectionPolicy. Jika tidak, Anda akan menghadapi masalah koneksi.

Membuat beberapa instans klien

Membuat beberapa instans klien dapat menyebabkan masalah ketidaksesuaian dan batas waktu koneksi. Diagnostik berisi dua properti yang relevan:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated melacak berapa kali dibuat CosmosClient dalam AppDomain yang sama, dan NumberOfActiveClients melacak klien aktif (tidak dibuang). Harapannya adalah bahwa jika pola singleton diikuti, X akan cocok dengan jumlah akun yang bekerja dengan aplikasi dan itu X sama Ydengan .

Jika X lebih besar dari Y, itu berarti aplikasi membuat dan membuang instans klien. Ini dapat menyebabkan pertikaian koneksi dan/atau ketidakcocokan CPU.

Solusi

Ikuti tips performa, dan gunakan satu instans CosmosClient per akun di seluruh proses. Hindari membuat dan membuang klien.

Kunci partisi panas

Azure Cosmos DB mendistribusikan throughput yang disediakan secara merata di seluruh partisi fisik. Ketika ada partisi panas, satu atau lebih kunci partisi logis fisik mengonsumsi semua Unit Permintaan partisi fisik per detik (RU/s). Pada saat yang sama, RU/s pada partisi fisik lainnya tidak akan digunakan. Sebagai gejala, total RU/s yang dikonsumsi akan kurang dari keseluruhan RU/s yang disediakan di database atau kontainer, tetapi pembatasan masih akan terlihat (429s) pada permintaan terhadap kunci partisi logis panas. Gunakan Metrik konsumsi RU Yang Dinormalisasi untuk melihat apakah beban kerja mengalami partisi panas.

Solusi

Pilih kunci partisi yang baik untuk mendistribusikan volume permintaan dan penyimpanan secara merata. Pelajari cara mengubah kunci partisi Anda.

Tingkat konkurensi tinggi

Aplikasi ini melakukan konkurensi tingkat tinggi, yang dapat menyebabkan ketidaksesuaian di saluran.

Solusi

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Permintaan atau respons besar

Permintaan atau respons besar dapat menyebabkan pemblokiran head-of-line di saluran dan memperparah ketidaksesuaian, bahkan dengan tingkat konkurensi yang relatif rendah.

Solusi

Aplikasi klien yang menggunakan SDK harus ditingkatkan atau diluaskan.

Tingkat kegagalan berada dalam SLA Azure Cosmos DB

Aplikasi harus dapat menangani kegagalan sementara dan mencoba kembali bila perlu. Pengecualian 408 apa pun tidak dicoba lagi karena di jalur pembuatan tidak mungkin untuk mengetahui apakah layanan membuat item atau tidak. Mengirim item yang sama lagi untuk pembuatan akan menyebabkan pengecualian konflik. Logika bisnis aplikasi pengguna mungkin memiliki logika kustom untuk menangani konflik, yang akan keluar dari ambiguitas item yang ada versus konflik dari coba lagi buat.

Tingkat kegagalan melanggar SLA Azure Cosmos DB

Hubungi Dukungan Azure.

Langkah berikutnya