Optimera lagringsplatsens prestanda

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Azure-lagringsplatser ger hög prestanda och tillförlitlighet för de flesta Git-lagringsplatser. Git fungerar bäst när lagringsplatser liknar typiska källkodsprojekt: filerna är relativt små, ändringarna är inkrementella och lokaliserade och katalogerna har en välorganiserad hierarki. De här villkoren gör att Git kan använda deltakomprimering och passera lagringsplatsträd effektivt.

När en lagringsplats inte uppfyller dessa villkor måste Git läsa och överföra fler och större objekt. Därför blir vanliga åtgärder, till exempel kloning, hämtning och surfning, långsammare.

Den här artikeln beskriver hur du analyserar lagringsplatsens hälsa, identifierar och löser vanliga orsaker till prestandaförsämring och minskar mängden data som överförs under kloner och hämtningar.

De resursgränser som gäller för lagringsplatser finns i Git-gränser.

Analys av repohälsa

Börja med den inbyggda panelen Hälsa och användning . Den sammanfattar lagringsplatsens storlek, antal objekt, referensantal och andra mått. Den visar också värden som närmar sig eller överskrider rekommenderade tröskelvärden.

Den här panelen kanske inte är tillgänglig i äldre versioner av Azure DevOps Server. Om du inte ser den kan du överväga att uppgradera till en nyare version för att få åtkomst till inbyggda hälsomått för lagringsplatser.

CLI-verktyg

För en närmare kontroll kör du följande verktyg mot en fullständig klon av lagringsplatsen.

git-sizer

Används git-sizer för en utvärdering på hög nivå av lagringsplatsens storlek och komplexitet. Den beräknar mått för hela lagringsplatsen och tilldelar en orosnivå till var och en. Ladda ned den senaste versionen från versionssidan och följ Komma igång för att köra verktyget och granska dess utdata.

git-lagringsplatsstruktur

Använd git repo structure som ett alternativ till git-sizer. Det här experimentella kommandot är utformat för att tillhandahålla liknande funktioner internt i vanliga Git. Mer information finns i Git-lagringsplatsens dokumentation.

git-undersökning

Använd git survey för analys på sökvägsnivå. Av dessa CLI-verktyg ger det den mest detaljerade uppdelningen. Den rangordnar de översta katalogerna och filerna efter antal objekt, diskstorlek och uppblåst storlek. Rapporten hjälper dig att identifiera de största bidragsgivarna till lagringsplatsens storlek och rikta in dem för rensning eller omstrukturering.

Det här kommandot ingår i Git för Windows och i Microsoft förgrening av Git. Tillgängligheten i andra Git-distributioner kan variera.

Tip

Lagringsplatsens tillväxt är enklast att tolka över tid. Kör dessa verktyg regelbundet och jämför resultaten för att spåra tillväxttrender och identifiera problematiska mönster tidigt.

Vanliga prestandaproblem och åtgärder för lagringsplatsen

Följande mönster är de vanligaste bidragsgivarna till lagringsplatsens tillväxt och försämrade prestanda.

Stora och ofta uppdaterade filer

Stora filer minskar Git-prestanda, oavsett om de är text eller binära. Effekten är störst när de ändras ofta. Eftersom varje ändring vanligtvis skriver om en stor del av filen blir deltakomprimering ineffektiv och gör att Git lagrar nästan en fullständig ögonblicksbild för varje revision. Därför växer lagringsplatsens storlek och antalet objekt snabbt.

  • Håll stora och ofta uppdaterade filer borta från Git. Lagra dem i Git LFS eller Azure Artifacts, och checka inte in byggutdata eller genererat innehåll. Mer information finns i Arbeta med stora filer på din Git-lagringsplats.
  • Om en stor fil måste finnas kvar i Git och ändras ofta delar du upp den i mindre logiska delar som kan versionshanteras oberoende av varandra.
  • Om du vill hindra nya stora filer från att komma in på lagringsplatsen aktiverar du principen Maximal filstorlek .

Använd Git LFS endast för stora filer som inte lämpar sig för diffning. Att flytta många små filer till LFS förbättrar inte prestandan och kan göra det värre.

Överdimensionerade eller platta katalogstrukturer

En katalog med många direkta poster, både filer och underkataloger, lagras som ett stort trädobjekt. Alla ändringar i det gör att Git skriver en ny kopia av hela objektet. Det här beteendet saktar ned Git-åtgärder och ökar lagringsplatsens storlek över tid, även när ändringarna är små.

Se till att antalet direktposter i en enskild katalog hålls på en hanterbar nivå. Ett antal över några hundra är ett tecken på att strukturen ska balanseras om.

  • Ordna objekt i en balanserad, hierarkisk struktur. Fördela filer och underkataloger jämnt så att ingen enskild katalog innehåller alltför många direkta objekt.
  • Om du behöver lagra en stor mängd genererade data på lagringsplatsen kan du partitionera dem i en kapslad layout, till exempel år/månad/dag.
  • Behåll genererat innehåll i en konsekvent ordning i varje fil. Att lägga till eller ta bort en liten mängd data bör bara påverka de relaterade raderna, inte ändra ordning på resten av filen och skapa ett stort diff. Du kan till exempel alltid sortera listobjekt på samma sätt.

Oanvända grenar

För många långlivade, oanvända grenar kan öka lagringsutrymmet och göra operationer långsammare. När du git clone har en lagringsplats laddar Git ned objekt som kan nås från varje fjärrgren, inklusive filer som aldrig har sammanfogats till main.

  • Ta bort inaktuella eller oanvända grenar regelbundet.
  • Om lagringsplatsen behöver ett mycket stort antal grenar kan du överväga att aktivera Begränsade referenser.

Båda åtgärderna minskar antalet referenser som klienterna och servern förhandlar om under varje hämtning.

Important

Azure-lagringsplatser lagring läggs endast till på servern. Rekommendationerna i den här artikeln förhindrar snabb framtida tillväxt, men de krymper inte en lagringsplats som redan har vuxit. Tidigare incheckade filer och kataloger finns kvar på servern. Att framtvinga eller ta bort en gren frigör inte det utrymmet. Det enda sättet att ta bort data helt är att återskapa lagringsplatsen och migrera bara det innehåll du behöver.

Snabba upp kloningar och hämtningar

Oavsett hur felfri en lagringsplats är kan klienter minska mängden data som de laddar ned:

  • En grund klon begränsar hur mycket historik som hämtas, vilket passar bra för CI som bara behöver de senaste commitarna.
  • En partiell klon bevarar hela historiken men hämtar endast filinnehåll när det behövs.

Mer information om båda alternativen finns i Git Partial Clone i Azure DevOps.

  • Uppdaterades senast