Felsöka registerprestanda

  • Artikel

Den här artikeln hjälper dig att felsöka problem som kan uppstå med prestanda för ett Azure-containerregister.

Symtom

Kan innehålla ett eller flera av följande:

  • Det tar längre tid än förväntat att hämta eller push-överföra avbildningar med Docker CLI
  • Distributionen av avbildningar till en tjänst som Azure Kubernetes Service tar längre tid än förväntat
  • Du kan inte slutföra ett stort antal samtidiga pull- eller push-åtgärder under den förväntade tiden
  • Du ser ett HTTP 429-fel som liknar Too many requests
  • Pull- eller push-åtgärder i ett geo-replikerat register tar längre tid än förväntat, eller push misslyckas med fel Error writing blob eller Error writing manifest

Orsaker

  • Nätverksanslutningshastigheten kan göra registeråtgärderna långsammare – lösningen
  • Komprimering eller extrahering av bildskikt kan vara långsamt på klienten – lösningen
  • Du når en konfigurerad gräns på registertjänstnivån eller i din miljö – lösning
  • Ditt geo-replikerade register har repliker i närliggande regioner – lösning
  • Du hämtar från en geografiskt avlägsen registerreplik – lösning

Om du inte löser problemet här läser du Avancerad felsökning och Nästa steg för andra alternativ.

Potentiella lösningar

Kontrollera förväntad nätverkshastighet

Kontrollera uppladdnings- och nedladdningshastigheten på Internet eller använd ett verktyg som AzureSpeed för att testa uppladdning och nedladdning från Azure Blob Storage, som är värd för registerbildskikt.

Kontrollera avbildningsstorleken mot den maximala storlek som stöds och den bandbredd som stöds för nedladdning eller uppladdning för registertjänstnivån. Om registret finns på basic- eller standardnivån bör du överväga att uppgradera för att förbättra prestandan.

För avbildningsdistribution till andra tjänster kontrollerar du de regioner där registret och målet finns. Överväg att hitta registret och distributionsmålet i samma eller nätverksnära regioner för att förbättra prestandan.

Relaterade länkar:

Kontrollera klientmaskinvara

Disktypen och PROCESSORn på Docker-klienten kan påverka hastigheten för att extrahera eller komprimera avbildningsskikt på klienten som en del av pull- eller push-åtgärder. Extrahering av lager på en hårddisk tar till exempel längre tid än på en solid state-disk. Jämför pull-åtgärder för jämförbara avbildningar från ditt Azure-containerregister och ett offentligt register, till exempel Docker Hub.

Granska konfigurerade gränser

Om du samtidigt push-överför eller hämtar flera eller många avbildningar i flera lager till registret läser du gränserna för ReadOps och WriteOps som stöds för registertjänstnivån. Om registret finns på basic- eller standardnivån kan du överväga att uppgradera för att öka gränserna. Kontakta även nätverksleverantören om nätverksbegränsning som kan inträffa med många samtidiga åtgärder.

Granska docker-daemonkonfigurationen för maximala samtidiga uppladdningar eller nedladdningar för varje push- eller pull-åtgärd på klienten. Konfigurera högre gränser om det behövs.

Eftersom varje avbildningslager kräver en separat läs- eller skrivåtgärd för registret kontrollerar du antalet lager i avbildningarna. Överväg strategier för att minska antalet bildskikt.

Relaterade länkar:

Konfigurera geo-replikerat register

En Docker-klient som push-överför en avbildning till ett geo-replikerat register kanske inte skickar alla avbildningslager och dess manifest till en enda replikerad region. Den här situationen kan inträffa eftersom Azure Traffic Manager dirigerar registerbegäranden till det nätverks närmaste replikerade registret. Om registret har två närliggande replikeringsregioner kan avbildningsskikt och manifestet distribueras till de två platserna, och push-åtgärden misslyckas när manifestet verifieras.

Om du vill optimera DNS-matchningen till närmaste replik vid push-överföring av avbildningar konfigurerar du ett geo-replikerat register i samma Azure-regioner som källan till push-åtgärderna, eller den närmaste regionen när du arbetar utanför Azure.

Om du vill felsöka åtgärder med ett geo-replikerat register kan du även tillfälligt inaktivera Traffic Manager-routning till en eller flera repliker.

Relaterade länkar:

Konfigurera DNS för geo-replikerat register

Om hämtningsåtgärder från ett geo-replikerat register visas långsamt kan DNS-konfigurationen på klienten matchas mot en geografiskt avlägsen DNS-server. I det här fallet kan Traffic Manager dirigera begäranden till en replik som ligger nära DNS-servern men som ligger långt från klienten. Kör ett verktyg som nslookup eller dig (på Linux) för att fastställa repliken som Traffic Manager dirigerar registerbegäranden till. Till exempel:

nslookup myregistry.azurecr.io

En potentiell lösning är att konfigurera en närmare DNS-server.

Relaterade länkar:

Avancerad felsökning

Om dina behörigheter till registerresurser tillåter kontrollerar du hälsotillståndet för registermiljön. Om fel rapporteras läser du felreferensen för potentiella lösningar.

Om insamling av resursloggar är aktiverad i registret läser du loggen ContainterRegistryRepositoryEvents. Den här loggen lagrar information för åtgärder som push- eller pull-händelser. Fråga loggen efter åtgärdsfel på lagringsplatsnivå.

Relaterade länkar:

Nästa steg

Om du inte löser problemet här kan du läsa följande alternativ.