Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Aşağıdaki bölümler, Azure Synapse Analytics'te işleri yönetmek için Spark havuzları ve API'ler için çeşitli sayısal sınırları listeler.
Kaynak sınırları
Aşağıdaki tablo, bireysel çalışma alanları ve Spark havuzları için iş ve çekirdeklerin maksimum sınırlarını göstermektedir.
Important
Spark havuzları için belirtilen sınırlar, düğüm boyutları, vCore ve bellek yapılandırmalarından bağımsızdır ve kullanıcıdan bağımsız olarak oluşturulan tüm Spark Havuzu örnekleri için geçerlidir, aksi belirtilmedikçe.
| Resource | Metric | Limit | Scope | Bölgeler | Notlar |
|---|---|---|---|---|---|
| Jobs | Eşzamanlı Çalışmak | 50 | Kıvılcım Havuzu | All | Limit, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. Örneğin, iki kullanıcı aynı Spark Pool'a karşı iş gönderiyorsa, iki kullanıcı için çalışan iş sayısı 50'yi geçemez. |
| Jobs | Kuyruğa alındı | 200 | Kıvılcım Havuzu | All | Limit, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. |
| Jobs | Maksimum Aktif İşler | 250 | Kıvılcım Havuzu | All | Limit, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. |
| Jobs | Maksimum Aktif İşler | 1000 | Workspace | All | |
| Çekirdekler | Kullanıcı Başına Çekirdek Sınırı | Havuz Tanımına Dayalı | Kıvılcım Havuzu | All | Örneğin, bir Spark havuzu 50 çekirdekli bir havuz olarak tanımlanıyorsa, her kullanıcı belirli bir Spark havuzunda en fazla 50 çekirdek kullanabilir, çünkü her kullanıcı havuzun kendi örneğine sahiptir. |
| Çekirdekler | Tüm Kullanıcılar Arasında Çekirdek Sınırı | Çalışma Alanı Tanımına Dayalı | Workspace | All | Örneğin, bir çalışma alanı 200 çekirdek sınırı varsa, çalışma alanı içindeki tüm havuzlardaki tüm kullanıcılar toplamda 200'den fazla çekirdek kullanamaz. |
| Livy | Livy talebi için maksimum yük boyutu | 100kBytes | Livy | All |
Note
- Maksimum Aktif İş, gönderilen toplam iş sayısıdır ve hem
Jobs Running SimultaneouslydeJobs Queued, yaniMax Active Jobs = Jobs Running Simultaneously + Jobs Queued
API hız sınırları
Aşağıdaki tablo, kıvılcım işi ve oturum yönetim API'leri için throttling limitlerini göstermektedir.
| Resource | Metric | Limit (Saniyede Sorgu) | Scope | Bölgeler |
|---|---|---|---|---|
| İşler API’si | Spark Oturumu Alma | 200 | Kıvılcım Oturumu | All |
| İşler API’si | Spark Oturumu Alma | 200 | Kıvılcım Havuzu | All |
| İşler API’si | Get Spark Deyimi | 200 | Kıvılcım Oturumu | All |
| İşler API’si | Birden Fazla Kıvılcım Açıklaması Alın | 200 | Kıvılcım Oturumu | All |
| İşler API’si | Oturum oluşturun | 2 | Workspace | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Batı Avrupa |
| İşler API’si | Oturum oluşturun | 2 | Workspace | Diğer tüm bölgeler |
| İşler API’si | Toplu İş Oluştur | 2 | Workspace | All |
| İşler API’si | Spark Batch İşi Alma | 200 | Workspace | All |
| İşler API’si | Çoklu Kıvılcım Toplu İş Alın | 200 | Workspace | All |
Note
Tüm kaynaklar ve işlemler için maksimum istek sınırı, tüm bölgeler için saniyede 200 sorgudur.
Tip
Eğer hata mesajı veya HTTP 429 yanıtı alırsanız
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)
Veya
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)
Kullanıcı, "Retry-After" HTTP yanıt başlığında verilen zaman dilimi değerini kullanarak, tekrar tekrarları yaparken o zaman aralığını beklemelidir.Yüksek trafik senaryolarında, tekrar denemeler için rastgele, sabit veya üstel bir zaman aralığı kullanmak yine de HTTP 429 hatalarına yol açar ve çok sayıda tekrar ile sonuçlanır; böylece isteklerin servis tarafından kabul edilmesi için geçen toplam süre artar.
Bunun yerine, Retry-After değer hizmeti kullanarak, kullanıcılar iş gönderimlerinde daha yüksek başarı oranı yaşayacak; çünkü değer saniye cinsinden nokta trafiğine göre hesaplanır ve tekrar deneme sayısı ile istemci isteklerinin sunucu tarafından kabul edilmesi için geçen süre optimize edilir