Azure Synapse Analytics'te Apache Spark havuzları için eşzamanlılık ve API hız sınırları
Aşağıdaki bölümlerde, Azure Synapse Analytics'te işleri yönetmek için Spark havuzları ve API'ler için çeşitli sayısal sınırlar listelemektedir.
Kaynak sınırları
Aşağıdaki tabloda, tek tek çalışma alanları ve Spark havuzları için iş ve çekirdek sınırları üst sınırı gösterilmektedir.
Önemli
Spark havuzları için belirtilen sınırlar düğüm boyutlarına, sanal çekirdeklerine ve bellek yapılandırmalarına bakılmaksızın geçerlidir ve aksi belirtilmedikçe kullanıcıdan bağımsız olarak spark havuzunun oluşturulan tüm örneklerine uygulanır.
| Kaynak | Ölçüm | Sınır | Kapsam | Bölgeler | Notlar |
|---|---|---|---|---|---|
| İşler | Aynı Anda Çalışıyor | 50 | Spark Havuzu | Tümü | Sınır, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. Örneğin, iki kullanıcı aynı Spark Havuzuna iş gönderirse, iki kullanıcı için çalışan işlerin toplam sayısı 50'yi aşamaz. |
| İşler | Kuyruğa alındı | 200 | Spark Havuzu | Tümü | Sınır, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. |
| İşler | En Fazla Etkin İş Sayısı | 250 | Spark Havuzu | Tümü | Sınır, Spark Havuzu tanımının tüm kullanıcıları için geçerlidir. |
| İşler | En Fazla Etkin İş Sayısı | 1000 | Çalışma alanı | Tümü | |
| Çekirdekler | Kullanıcı Başına Çekirdek Sınırı | Havuz Tanımına Göre | Spark Havuzu | Tümü | Örneğin, bir Spark havuzu 50 çekirdekli havuz olarak tanımlanırsa, her kullanıcı kendi havuzunun örneğini aldığından, her kullanıcı belirli Bir Spark havuzu içinde en fazla 50 çekirdek kullanabilir. |
| Çekirdekler | Tüm Kullanıcılar Genelinde Çekirdek Sınırı | Çalışma Alanı Tanımına Göre | Çalışma alanı | Tümü | Örneğin, bir çalışma alanı 200 çekirdek sınırına sahipse, çalışma alanı içindeki tüm havuzlardaki tüm kullanıcılar 200'den fazla çekirdeği bir arada kullanamaz. |
| Livy | Livy isteği için Maksimum Yük boyutu | 100kBytes | Livy | Tümü |
Not
- En Fazla Etkin İş, hem hem de
Jobs Running SimultaneouslyJobs Queuediçeren gönderilen toplam iş sayısıdır; örneğin,Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
API hız sınırları
Aşağıdaki tabloda Spark işi ve oturum yönetimi API'leri için azaltma sınırları gösterilmektedir.
| Kaynak | Ölçüm | Sınır (Saniye Başına Sorgu sayısı) | Kapsam | Bölgeler |
|---|---|---|---|---|
| İşler API’si | Spark Oturumu Alma | 200 | Spark Oturumu | Tümü |
| İşler API’si | Spark Oturumu Alma | 200 | Spark Havuzu | Tümü |
| İşler API’si | Get Spark Deyimi | 200 | Spark Oturumu | Tümü |
| İşler API’si | Birden Çok Spark Deyimi Alma | 200 | Spark Oturumu | Tümü |
| İşler API’si | Oturum Oluştur | 2 | Çalışma alanı | EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Batı Avrupa |
| İşler API’si | Oturum Oluştur | 2 | Çalışma alanı | Diğer tüm bölgeler |
| İşler API’si | Toplu İş Oluştur | 2 | Çalışma alanı | Tümü |
| İşler API’si | Spark Batch İşi Alma | 200 | Çalışma alanı | Tümü |
| İşler API’si | Birden Çok Spark Batch İşi Alma | 200 | Çalışma alanı | Tümü |
Not
Tüm kaynaklar ve işlemler için istek sayısı üst sınırı, tüm bölgeler için saniyede 200 sorgudur.
İpucu
Okunan bir hata iletisi 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ı, yeniden denemeler gerçekleştirirken bu zaman aralığını beklemek için "Yeniden Dene-Sonra" HTTP yanıt üst bilgisinde sağlanan zaman aralığı değerini kullanmalıdır.Yüksek trafikli senaryolarda, yeniden denemeler için rastgele, sabit veya üstel bir zaman aralığı kullanılması HTTP 429 hatalarına neden olmaya devam eder ve isteklerin hizmet tarafından kabul edilme süresini artırarak yüksek sayıda yeniden denemeye neden olur.
Bunun yerine, sağlanan hizmeti Retry-After değeri kullanarak, istemci isteklerinin sunucu tarafından kabul edilmesi için yeniden deneme sayısını ve geçen süreyi iyileştirmek üzere saniye içindeki değer belirli bir noktaya göre hesaplandığından, kullanıcılar iş gönderimlerinde daha yüksek başarı oranıyla karşılaşır.