Azure Synapse Analytics での Apache Spark プールのコンカレンシーと API レートの制限
次のセクションでは、Azure Synapse Analytics でジョブを管理するための Spark プールと API に関するさまざまな数値制限について説明します。
リソース制限
次の表は、個々のワークスペースと Spark プールのジョブとコアの上限を示しています。
重要
Spark プールに指定された制限は、ノード サイズ、仮想コア、およびメモリ構成に関係なく、特に明記されていない限り、ユーザーに関係なく、Spark プールのすべての作成されたインスタンスに適用されます。
| リソース | メトリック | 制限 | Scope | リージョン | Notes |
|---|---|---|---|---|---|
| ジョブ | 同時に実行する | 50 | Spark プール | すべて | 制限は、Spark プール定義のすべてのユーザーに適用されます。 たとえば、2 人のユーザーが同じ Spark プールに対してジョブを送信している場合、2 人のユーザーに対して実行されているジョブの累積数は 50 を超えることはできません。 |
| ジョブ | キューに登録済み | 200 | Spark プール | すべて | 制限は、Spark プール定義のすべてのユーザーに適用されます。 |
| ジョブ | アクティブなジョブの最大数 | 250 | Spark プール | すべて | 制限は、Spark プール定義のすべてのユーザーに適用されます。 |
| ジョブ | アクティブなジョブの最大数 | 1000 | ワークスペース | All | |
| コア | ユーザーあたりのコア数の制限 | プール定義に基づく | Spark プール | すべて | たとえば、Spark プールが 50 コア プールとして定義されている場合、各ユーザーはプールの独自のインスタンスを取得するため、各ユーザーは特定の Spark プール内で最大 50 個のコアを使用できます。 |
| コア | すべてのユーザーのコア数の制限 | ワークスペース定義に基づく | ワークスペース | All | たとえば、ワークスペースに 200 コアの制限がある場合、ワークスペース内のすべてのプールのすべてのユーザーが 200 個を超えるコアを組み合わせて使用することはできません。 |
| Livy | Livy 要求の最大ペイロード サイズ | 100kBytes | Livy | すべて |
注意
- アクティブなジョブの最大数は、送信されたジョブの合計数です。これには、 と
Jobs Queuedの両方Jobs Running Simultaneouslyが含まれます。つまり、Max Active Jobs = Jobs Running Simultaneously + Jobs Queued
API のレート制限
次の表は、Spark ジョブとセッション管理 API の調整の制限を示しています。
| リソース | メトリック | 制限 (1 秒あたりのクエリ数) | Scope | リージョン |
|---|---|---|---|---|
| ジョブ API | Spark セッションを取得する | 200 | Spark セッション | すべて |
| ジョブ API | Spark セッションを取得する | 200 | Spark プール | すべて |
| ジョブ API | Spark ステートメントを取得する | 200 | Spark セッション | すべて |
| ジョブ API | 複数の Spark ステートメントを取得する | 200 | Spark セッション | すべて |
| ジョブ API | セッションの作成 | 2 | ワークスペース | EastUS、EastUS2、WestUS、WestUS2、CentralUS、EastUS2EUAP、西ヨーロッパ |
| ジョブ API | セッションの作成 | 2 | ワークスペース | その他のすべてのリージョン |
| ジョブ API | バッチ ジョブの作成 | 2 | ワークスペース | All |
| ジョブ API | Spark Batch ジョブを取得する | 200 | ワークスペース | All |
| ジョブ API | 複数の Spark バッチ ジョブを取得する | 200 | ワークスペース | すべて |
注意
すべてのリソースと操作の要求の上限は、すべてのリージョンで 1 秒あたり 200 クエリです。
ヒント
を読み取るエラー メッセージまたは HTTP 429 応答が表示される場合
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)
または
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)
ユーザーは、"Retry-After" HTTP 応答ヘッダーで指定された期間の値を使用して、再試行を実行するときにその時間間隔を待機する必要があります。トラフィックが多いシナリオでは、再試行にランダム、定数、または指数時間間隔を使用しても、HTTP 429 エラーが発生し、再試行回数が多くなります。これにより、要求がサービスによって受け入れられるまでに要する全体的な時間が長くなります。
代わりに、Retry-After値を指定したサービスを使用すると、クライアントの要求がサーバーによって受け入れられる再試行回数と所要時間を最適化するために、ポイントインタイム トラフィックに基づいて秒単位の値が計算されるため、ユーザーはジョブの送信で成功率が高くなります。