Egyidejűségi és API-sebességkorlátok az Apache Spark-készletekhez az Azure Synapse Analyticsben

Az alábbi szakaszok a Spark-készletek és API-k különböző numerikus korlátait sorolják fel a feladatok Azure Synapse Analyticsben való kezeléséhez.

Erőforráskorlátok

Az alábbi táblázat az egyes munkaterületekre és Spark-készletekre vonatkozó feladatok és magok maximális korlátait mutatja be.

Fontos

A Spark-készletekhez megadott korlátok a csomópontmérettől, a virtuális magtól és a memóriakonfigurációtól függetlenül érvényesek a Spark-készlet összes létrehozott példányára, függetlenül a felhasználótól, hacsak másként nem jelezzük.

Erőforrás Metrika Korlát Hatókör Régiók Jegyzetek
Feladatok Egyidejű futtatás 50 Spark-készlet Mind A korlátozás a Spark-készlet definíciójának összes felhasználójára vonatkozik. Ha például két felhasználó ugyanarra a Spark-készletre küld feladatokat, akkor a két felhasználó által futtatott feladatok összesített száma nem haladhatja meg az 50-et.
Feladatok Várólistán 200 Spark-készlet Mind A korlátozás a Spark-készlet definíciójának összes felhasználójára vonatkozik.
Feladatok Aktív feladatok maximális száma 250 Spark-készlet Mind A korlátozás a Spark-készlet definíciójának összes felhasználójára vonatkozik.
Feladatok Aktív feladatok maximális száma 1000 Munkaterület Mind
Cores Magok korlátja felhasználónként A készletdefiníció alapján Spark-készlet Mind Ha például egy Spark-készlet 50 magos készletként van definiálva, minden felhasználó legfeljebb 50 magot használhat az adott Spark-készleten belül, mivel minden felhasználó saját példányt kap a készletből.
Cores Magok korlátozása minden felhasználóra Munkaterület-definíció alapján Munkaterület Mind Ha például egy munkaterület 200 magos korláttal rendelkezik, akkor a munkaterületen belüli összes készlet összes felhasználója nem használhat egyszerre több mint 200 magot.
Livy Livy-kérelem maximális hasznos adatmérete 100 kb Livy Mind

Megjegyzés

  • A maximális aktív feladatok a beküldött feladatok teljes száma, amely magában foglalja a és Jobs Queueda feladatot isJobs Running Simultaneously, azazMax Active Jobs = Jobs Running Simultaneously + Jobs Queued

API-sebességkorlátok

Az alábbi táblázat a Spark-feladat és a munkamenet-kezelési API-k szabályozási korlátait mutatja be.

Erőforrás Metrika Korlát (lekérdezések másodpercenként) Hatókör Régiók
Jobs API Spark-munkamenet beolvasása 200 Spark-munkamenet Mind
Jobs API Spark-munkamenet beolvasása 200 Spark-készlet Mind
Jobs API Spark-utasítás lekérése 200 Spark-munkamenet Mind
Jobs API Több Spark-utasítás lekérése 200 Spark-munkamenet Mind
Jobs API Munkamenet létrehozása 2 Munkaterület EastUS, EastUS2, WestUS, WestUS2, CentralUS, EastUS2EUAP, Nyugat-Európa
Jobs API Munkamenet létrehozása 2 Munkaterület Minden egyéb régió
Jobs API Batch-feladat létrehozása 2 Munkaterület Mind
Jobs API Spark Batch-feladat lekérése 200 Munkaterület Mind
Jobs API Több Spark Batch-feladat lekérése 200 Munkaterület Mind

Megjegyzés

Az összes erőforrásra és műveletre vonatkozó kérelmek maximális korlátja másodpercenként 200 lekérdezés minden régióban.

Tipp

Ha hibaüzenet vagy HTTP 429-válasz jelenik meg, amely

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)

Vagy

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)

A felhasználónak az "Újrapróbálkozás után" HTTP-válaszfejlécben megadott időintervallumot kell használnia, hogy megvárja az adott időtartamot az újrapróbálkozások végrehajtásakor.A nagy forgalmú forgatókönyvekben az újrapróbálkozások véletlenszerű, állandó vagy exponenciális időintervallumának használata továbbra is HTTP 429-es hibákat eredményezne, és nagy számú újrapróbálkozást eredményezne, mivel növeli a kérések szolgáltatás általi elfogadásához szükséges teljes időt.

Ehelyett a megadott Retry-After érték használatával a felhasználók nagyobb sikerességi arányt tapasztalnának a feladatbeküldésekben, mivel a másodpercben megadott értéket az időérték alapján számítják ki, hogy optimalizálják az újrapróbálkozások számát és az ügyfél kéréseinek a kiszolgáló által történő elfogadásához szükséges időt.

Következő lépések