Limity szybkości współbieżności i interfejsu API dla pul platformy Apache Spark w usłudze Azure Synapse Analytics

  • Artykuł

W poniższych sekcjach wymieniono różne limity liczbowe dla pul platformy Spark i interfejsów API do zarządzania zadaniami w usłudze Azure Synapse Analytics.

Limity zasobów

W poniższej tabeli przedstawiono maksymalne limity zadań i rdzeni dla poszczególnych obszarów roboczych i pul platformy Spark.

Ważne

Limity określone dla pul platformy Spark są niezależnie od ich rozmiarów węzłów, rdzeni wirtualnych i konfiguracji pamięci oraz mają zastosowanie do wszystkich utworzonych wystąpień puli spark niezależnie od użytkownika, chyba że określono inaczej.

Zasób Metric Limit Zakres Regiony Uwagi
Stanowiska Uruchamianie jednocześnie 50 Pula platformy Spark Wszystko Limit dotyczy wszystkich użytkowników definicji puli platformy Spark. Jeśli na przykład dwóch użytkowników przesyła zadania względem tej samej puli platformy Spark, łączna liczba zadań uruchomionych dla dwóch użytkowników nie może przekroczyć 50.
Stanowiska W kolejce 200 Pula platformy Spark Wszystko Limit dotyczy wszystkich użytkowników definicji puli platformy Spark.
Stanowiska Maksymalna liczba aktywnych zadań 250 Pula platformy Spark Wszystko Limit dotyczy wszystkich użytkowników definicji puli platformy Spark.
Stanowiska Maksymalna liczba aktywnych zadań 1000 Workspace Wszystko
Rdzenie Limit rdzeni na użytkownika Na podstawie definicji puli Pula platformy Spark Wszystko Jeśli na przykład pula Spark jest zdefiniowana jako pula 50 rdzeni, każdy użytkownik może używać maksymalnie 50 rdzeni w ramach określonej puli Spark, ponieważ każdy użytkownik otrzymuje własne wystąpienie puli.
Rdzenie Limit rdzeni dla wszystkich użytkowników Na podstawie definicji obszaru roboczego Workspace Wszystko Jeśli na przykład obszar roboczy ma limit 200 rdzeni, wszyscy użytkownicy we wszystkich pulach w obszarze roboczym nie mogą używać łącznie więcej niż 200 rdzeni.
Livy Maksymalny rozmiar ładunku dla żądania usługi Livy 100kBajty Livy Wszystko

Uwaga

  • Maksymalna liczba przesłanych aktywnych zadań to łączna liczba przesłanych zadań, łącznie z Jobs Running Simultaneously elementami i Jobs Queued, tj. Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

Limity szybkości interfejsu API

W poniższej tabeli przedstawiono limity ograniczania przepustowości dla interfejsów API zarządzania zadaniami i sesjami platformy Spark.

Zasób Metric Limit (zapytania na sekundę) Zakres Regiony
Interfejs API zadań Uzyskiwanie sesji platformy Spark 200 Sesja platformy Spark Wszystko
Interfejs API zadań Uzyskiwanie sesji platformy Spark 200 Pula platformy Spark Wszystko
Interfejs API zadań Get Spark, instrukcja 200 Sesja platformy Spark Wszystko
Interfejs API zadań Pobieranie wielu instrukcji platformy Spark 200 Sesja platformy Spark Wszystko
Interfejs API zadań Tworzenie sesji 2 Workspace EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Europa Zachodnia
Interfejs API zadań Tworzenie sesji 2 Workspace Wszystkie inne regiony:
Interfejs API zadań Tworzenie zadania usługi Batch 2 Workspace Wszystko
Interfejs API zadań Pobieranie zadania usługi Spark Batch 200 Workspace Wszystko
Interfejs API zadań Pobieranie wielu zadań usługi Spark Batch 200 Workspace Wszystko

Uwaga

Maksymalny limit żądań dla wszystkich zasobów i operacji wynosi 200 zapytań na sekundę dla wszystkich regionów.

Porada

Jeśli zostanie wyświetlony komunikat o błędzie lub odpowiedź HTTP 429, która odczytuje

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)

Lub

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)

Użytkownik powinien użyć wartości okresu czasu podanej w nagłówku odpowiedzi HTTP "Retry-After", aby poczekać na ten interwał czasu podczas przeprowadzania ponownych prób.W scenariuszach o dużym natężeniu ruchu użycie losowego, stałego lub wykładniczego interwału czasu dla ponownych prób nadal spowoduje błędy HTTP 429 i spowoduje powstanie dużej liczby ponownych prób, co zwiększy całkowity czas potrzebny na zaakceptowanie żądań przez usługę.

Zamiast tego przy użyciu podanej usługi Retry-After wartość użytkownicy będą doświadczać wyższego współczynnika powodzenia w przesyłaniu zadań, ponieważ wartość w sekundach jest obliczana na podstawie ruchu w czasie w celu zoptymalizowania liczby ponownych prób i czasu potrzebnego na zaakceptowanie żądań klienta przez serwer

Następne kroki