你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Synapse Analytics 中 Apache Spark 池的并发和 API 速率限制

以下部分列出了用于管理 Azure Synapse Analytics 中作业的 Spark 池和 API 的各种数字限制。

资源限制

下表显示了单个工作区和 Spark 池的作业和核心的最大限制。

重要

为 Spark 池指定的限制不考虑其节点大小、vCore 和内存配置,并适用于 Spark 池的所有创建实例,而不考虑用户,除非另有说明。

资源 指标 限制 范围 区域 注释
作业 同时运行 50 SPARK 池 全部 限制适用于 Spark 池定义的所有用户。 例如,如果两个用户针对同一 Spark 池提交作业,则为两个用户运行的累计作业数不能超过 50。
作业 已排队 200 SPARK 池 全部 限制适用于 Spark 池定义的所有用户。
作业 最大活动作业数 250 SPARK 池 全部 限制适用于 Spark 池定义的所有用户。
作业 最大活动作业数 1000 工作区 全部
核心数 每个用户的核心数限制 基于池定义 SPARK 池 全部 例如,如果将 Spark 池定义为 50 核池,则每个用户最多可以使用特定 Spark 池中的 50 个核心,因为每个用户都获取其自己的池实例。
核心数 所有用户的核心限制 基于工作区定义 工作区 全部 例如,如果工作区的内核数限制为 200 个,则工作区中所有池中的所有用户不能使用超过 200 个核心。
Livy Livy 请求的最大有效负载大小 100kBytes Livy 全部

注意

  • 最大活动作业数是提交的作业总数,包括 Jobs Running SimultaneouslyJobs Queued,即 Max Active Jobs = Jobs Running Simultaneously + Jobs Queued

速率限制

下表显示了 Spark 作业和会话管理 API 的限制。

资源 指标 限制每秒 (查询数) 范围 区域
作业 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 工作区 全部
作业 API 获取 Spark Batch 作业 200 工作区 全部
作业 API 获取多个 Spark Batch 作业 200 工作区 全部

注意

所有资源和操作的最大请求限制是所有区域的每秒 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)

用户应使用“重试后”HTTP 响应标头中提供的时间段值,在执行重试时等待该时间间隔。在高流量方案中,对重试使用随机、固定或指数时间间隔仍会导致 HTTP 429 失败,并且会导致大量重试,从而增加服务接受请求所需的总时间。

相反,通过使用Retry-After值提供的服务,用户在提交作业时会体验到更高的成功率,因为以秒为单位的值基于时间点流量来计算,以优化重试次数和服务器接受客户端请求所花费的时间

后续步骤