通过

解决“超出作业大小”错误

  • 项目

本文介绍如何解决 JobSizeExceededException 和 DeploymentJobSizeExceededException 错误。 部署 Bicep 文件或 Azure 资源管理器模板（ARM 模板）时，可能会出现作业大小超出错误。

症状

部署模板时收到一条错误，指出部署已超出限制。

原因

当部署超过允许的大小限制时，会出现此错误。 模板或部署作业太大时，通常会显示此错误。 请注意，在验证模板大小以进行部署之前，模板会被压缩，因此有效限制可能大于模板的实际大小。

部署作业大小限制为压缩后 1 MB，这包括请求的元数据。 对于大型模板，元数据和模板的组合大小可能超过此限制。

压缩后的模板大小本身不能超过 4 MB，每个单独的资源定义在压缩后不能超过 1 MB。 这些限制适用于使用循环创建多个实例的任何资源定义在扩展后的模板最终状态，其中包括所有变量和参数解析后的值。

其他模板限制包括：

  • 256 个参数
  • 256 个变量
  • 800 个资源（包括副本计数）
  • 64 个输出值
  • 模板表达式中不超过 24,576 个字符

解决方案 1：减小名称大小

请尝试缩短用于参数、变量和输出的名称的长度。 当这些值在循环中重复时，长名称会被相乘很多次。

解决方案 2：简化模板

在你的文件部署大量不同的资源类型时，请考虑将这些资源类型划分为模块。 将你的资源类型划分为逻辑组，并为每个组添加模块。 例如，如果需要部署大量网络资源，则可将这些资源移动到某个模块。

可将其他资源设置为隐式依赖项，并从模块的输出获取值。

使用模板规格，而不是 Bicep 模块。 Bicep 模块将转换为包含嵌套模板的单个 ARM 模板。

解决方案 3：谨慎使用依赖项

使用在某个资源按其符号名称引用另一资源时创建的隐式依赖项。 对于大多数部署，不必使用 dependsOn 并创建显式依赖项。

复杂的依赖项会快速消耗数据限制。 例如，如果 n 资源的循环取决于另一个 n 资源的循环，会导致存储 O(n²) 数据。 相比之下，如果一个循环中的每个资源只依赖于另一个循环中的对应资源，会导致 O(n) 数据。 这种差异可能看起来很细微，但对存储的影响增长得非常快。

解决方案 4：减少不可压缩的数据

在模板或参数中包含大量不可压缩的数据（例如证书或二进制文件）或压缩率较低的数据将很快消耗大小限制。