Lösa fel för att jobbstorleken har överskridits

I den här artikeln beskrivs hur du löser felen JobSizeExceededException och DeploymentJobSizeExceededException . Fel som överskrider jobbstorleken kan inträffa när du distribuerar en Bicep-fil eller En Azure Resource Manager-mall (ARM-mall).

Symptom

När du distribuerar en mall får du ett felmeddelande om att distributionen har överskridit gränserna.

Orsak

Det här felet uppstår när distributionen överskrider de tillåtna storleksgränserna. Det visas vanligtvis när mallen eller distributionsjobbet är för stort. Observera att mallar komprimeras innan deras storlekar verifieras för distribution, så de effektiva gränserna kan vara större än mallens faktiska storlek.

Storleksgränsen för distributionsjobbet är 1 MB efter komprimering, inklusive metadata om begäran. För stora mallar kan den kombinerade storleken på metadata och mallen överskrida den här gränsen.

Själva den komprimerade mallstorleken får inte överstiga 4 MB och varje enskild resursdefinition får inte överstiga 1 MB efter komprimering. Dessa gränser gäller för mallens slutliga tillstånd efter expansionen för alla resursdefinitioner som använder loopar för att skapa flera instanser, vilket inkluderar lösta värden för alla variabler och parametrar.

Andra mallgränser är:

• 256 parametrar
• 256 variabler
• 800 resurser (inklusive antal kopior)
• 64 utdatavärden
• 24 576 tecken i ett malluttryck

Lösning 1: Minska namnstorleken

Bicep

Försök att förkorta längden på de namn som du använder för parametrar, variabler och utdata. När dessa värden upprepas i loopar multipliceras ett långt namn många gånger.

JSON

Försök att förkorta längden på de namn som du använder för parametrar, variabler och utdata. När dessa värden upprepas via kopieringsloopar multipliceras ett långt namn många gånger.

Lösning 2: Förenkla mallen

Bicep

När filen distribuerar många olika resurstyper bör du överväga att dela upp den i moduler. Dela upp resurstyperna i logiska grupper och lägg till en modul för varje grupp. Om du till exempel behöver distribuera många nätverksresurser kan du flytta resurserna till en modul.

Du kan ange andra resurser som implicita beroenden och hämta värden från utdata från moduler.

Använd mallspecifikationer i stället för Bicep-moduler. Bicep-moduler konverteras till en enda ARM-mall med kapslade mallar.

JSON

När mallen distribuerar många olika resurstyper bör du överväga att dela upp den i länkade mallar. Dela upp resurstyperna i logiska grupper och lägg till en länkad mall för varje grupp. Om du till exempel behöver distribuera många nätverksresurser kan du flytta dessa resurser till en länkad mall.

Du kan ange andra resurser som beroende av den länkade mallen och hämta värden från utdata från den länkade mallen.

Använd mallspecifikationer i stället för kapslade mallar.

Lösning 3: Använd beroenden noggrant

Bicep

Använd ett implicit beroende som skapas när en resurs refererar till en annan resurs med dess symboliska namn. För de flesta distributioner är det inte nödvändigt att använda dependsOn och skapa ett explicit beroende.

JSON

När du använder kopieringsloopar för att distribuera resurser ska du inte använda loopnamnet som ett beroende:

dependsOn: [ "nicLoop" ]

Använd i stället resursinstansen från den loop som du behöver vara beroende av. Till exempel:

dependsOn: [
    "[resourceId('Microsoft.Network/networkInterfaces', concat('nic-', copyIndex()))]"
]

Komplexa beroenden kan snabbt förbruka datagränserna. Om en loop med n-resurser till exempel är beroende av en annan loop med n resurser, resulterar det i att O(n²) data lagras. Om varje resurs i en loop däremot bara är beroende av dess motsvarighet i den andra loopen resulterar den i O(n) data. Den här skillnaden kan verka diskret, men lagringspåverkan växer mycket snabbt.

Lösning 4: Minska okomprimerbara data

Om du inkluderar stora mängder okomprimerbara data, till exempel certifikat eller binärfiler, eller data med ett lågt komprimeringsförhållande i en mall eller parametrar, kommer storleksgränsen snabbt att förbrukas.