Batas konkurensi dan laju API untuk kumpulan Apache Spark di Azure Synapse Analytics

  • Artikel

Bagian berikut mencantumkan berbagai batas numerik untuk kumpulan Spark dan API untuk mengelola pekerjaan di Azure Synapse Analytics.

Batas Sumber Daya

Tabel berikut menunjukkan batas maksimum pekerjaan dan inti untuk masing-masing ruang kerja dan kumpulan Spark.

Penting

Batas yang ditentukan untuk kumpulan Spark terlepas dari ukuran simpul, vCore, dan konfigurasi memorinya dan berlaku untuk semua instans yang dibuat dari Kumpulan Spark terlepas dari pengguna kecuali dinyatakan lain.

Sumber daya Metrik Batas Cakupan Wilayah Catatan
Pekerjaan Berjalan Secara Bersamaan 50 Kumpulan Spark Semua Batas berlaku di semua pengguna definisi Kumpulan Spark. Misalnya, jika dua pengguna mengirimkan pekerjaan terhadap Kumpulan Spark yang sama, maka jumlah kumulatif pekerjaan yang berjalan untuk dua pengguna tidak boleh melebihi 50.
Pekerjaan Dalam antrean 200 Kumpulan Spark Semua Batas berlaku di semua pengguna definisi Kumpulan Spark.
Pekerjaan Pekerjaan Aktif Maksimum 250 Kumpulan Spark Semua Batas berlaku di semua pengguna definisi Kumpulan Spark.
Pekerjaan Pekerjaan Aktif Maksimum 1000 Ruang kerja Semua
Core Batas Inti Per Pengguna Berdasarkan Definisi Kumpulan Kumpulan Spark Semua Misalnya, jika kumpulan Spark didefinisikan sebagai kumpulan 50-core, setiap pengguna dapat menggunakan hingga 50 inti dalam kumpulan Spark tertentu, karena setiap pengguna mendapatkan instans kumpulannya sendiri.
Core Batas Inti di Semua Pengguna Berdasarkan Definisi Ruang Kerja Ruang kerja Semua Misalnya, jika ruang kerja memiliki batas 200 core, semua pengguna di semua kumpulan dalam ruang kerja tidak dapat menggunakan lebih dari 200 core yang digabungkan.
Livy Ukuran Payload Maks untuk permintaan Livy 100kByte Livy Semua

Catatan

  • Pekerjaan Aktif Maksimum adalah jumlah total pekerjaan yang dikirimkan, yang mencakup Jobs Running Simultaneously dan Jobs Queued, yaitu, Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Batas tarif API

Tabel berikut menunjukkan batas pembatasan untuk api manajemen sesi dan pekerjaan spark.

Sumber daya Metrik Batas (Kueri per Detik) Cakupan Wilayah
API Pekerjaan Dapatkan Sesi Spark 200 Sesi Spark Semua
API Pekerjaan Dapatkan Sesi Spark 200 Kumpulan Spark Semua
API Pekerjaan Dapatkan Pernyataan Spark 200 Sesi Spark Semua
API Pekerjaan Mendapatkan Beberapa Pernyataan Spark 200 Sesi Spark Semua
API Pekerjaan Buat Sesi 2 Ruang kerja EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Eropa Barat
API Pekerjaan Buat Sesi 2 Ruang kerja Semua wilayah lainnya
API Pekerjaan Membuat Tugas Batch 2 Ruang kerja Semua
API Pekerjaan Mendapatkan Pekerjaan Batch Spark 200 Ruang kerja Semua
API Pekerjaan Mendapatkan Beberapa Pekerjaan Batch Spark 200 Ruang kerja Semua

Catatan

Batas permintaan maksimum untuk semua sumber daya dan operasi adalah 200 kueri per detik untuk semua wilayah.

Tip

Jika Anda mendapatkan pesan kesalahan atau respons HTTP 429 yang membaca

Your request has hit layered throttling rate-limit of 200 requests per 1 second(s) for requests on resource(s) identified by pattern {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 282 requests per 1 second(s). Please retry after 1 second(s)

Atau

Your request has hit layered throttling rate-limit of 2 requests per 1 second(s) for requests on resource(s) identified by {subscriptionId}. {workspaceName}. {HTTP-Verb}. {operationName} - You are currently hitting at a rate of 24 requests per 1 second(s). Please retry after 1 second(s)

Pengguna harus menggunakan nilai periode waktu yang disediakan di header respons HTTP "Coba Lagi-Setelah", untuk menunggu interval waktu tersebut saat melakukan percobaan ulang.Dalam skenario lalu lintas yang tinggi, menggunakan interval waktu acak, konstan atau eksponensial untuk percobaan ulang masih akan mengakibatkan kegagalan HTTP 429 dan akan menimbulkan jumlah percobaan ulang yang tinggi, dengan meningkatkan waktu keseluruhan yang diperlukan agar permintaan diterima oleh layanan.

Sebaliknya dengan menggunakan layanan yang disediakan Retry-After nilai, pengguna akan mengalami tingkat keberhasilan yang lebih tinggi dalam pengiriman pekerjaan karena nilai dalam hitungan detik dihitung berdasarkan lalu lintas titik waktu untuk mengoptimalkan jumlah percobaan ulang dan waktu yang diperlukan untuk permintaan klien yang akan diterima oleh server

Langkah berikutnya