Prestaties van opslagplaats optimaliseren

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

Azure-opslagplaatsen biedt hoge prestaties en betrouwbaarheid voor de meeste Git-opslagplaatsen. Git werkt het beste wanneer opslagplaatsen lijken op typische broncodeprojecten: bestanden zijn relatief klein, wijzigingen zijn incrementeel en gelokaliseerd en mappen hebben een goed georganiseerde hiërarchie. Met deze voorwaarden kan Git deltacompressie gebruiken en opslagplaatsstructuren efficiënt doorkruisen.

Wanneer een opslagplaats niet aan deze voorwaarden voldoet, moet Git meer en grotere objecten lezen en overdragen. Als gevolg hiervan worden veelvoorkomende bewerkingen, zoals klonen, ophalen en bladeren, langzamer.

In dit artikel wordt uitgelegd hoe u de status van de opslagplaats analyseert, veelvoorkomende oorzaken van prestatievermindering identificeert en oplost, en hoe u de hoeveelheid overgedragen gegevens tijdens klonen en ophalen vermindert.

Zie Git-limieten voor de resourcelimieten die van toepassing zijn op opslagplaatsen.

Gezondheidsanalyse van repository

Begin met het ingebouwde paneel Gezondheid en gebruik. Het bevat een overzicht van de grootte van de opslagplaats, het aantal objecten, het aantal verwijzingen en andere metrische gegevens. Ook worden waarden gemarkeerd die de aanbevolen drempelwaarden naderen of overschrijden.

Dit deelvenster is mogelijk niet beschikbaar in oudere versies van Azure DevOps Server. Als u dit niet ziet, overweeg dan te upgraden naar een nieuwere versie om toegang te krijgen tot ingebouwde statusmetingen van de repository.

CLI-hulpprogramma's

Voer voor een nadere inspectie de volgende hulpprogramma's uit op een volledige kloon van de repository.

git-sizer

Gebruik git-sizer deze functie voor een evaluatie op hoog niveau van de grootte en complexiteit van de opslagplaats. Hiermee worden metrische gegevens voor de hele opslagplaats berekend en wordt een zorgniveau aan elk gegeven toegewezen. Download de nieuwste versie van de releasepagina en volg Aan de slag om het hulpprogramma uit te voeren en de uitvoer ervan te controleren.

Git-opslagplaatsstructuur

Gebruik git repo structure als alternatief voor git-sizer. Deze experimentele opdracht is ontworpen om een vergelijkbare functionaliteit te bieden in standaard Git. Zie de documentatie van de Git-opslagplaats voor meer informatie.

git enquête

Gebruik git survey voor analyse op padniveau. Van deze CLI-hulpprogramma's biedt het de meest gedetailleerde uitsplitsing. Het rangschikt de beste mappen en bestanden op objectaantal, schijfgrootte en vergrootte grootte. Het rapport helpt u de grootste bijdragers aan de grootte van de repository te identificeren en deze gericht aan te pakken met opschoning of herstructurering.

Deze opdracht is opgenomen in Git voor Windows en in de fork van Git van Microsoft. De beschikbaarheid in andere Git-distributies kan variëren.

Veelvoorkomende prestatieproblemen en oplossingen voor opslagplaatsen

De volgende patronen zijn de meest voorkomende bijdragers aan groei van opslagplaatsen en verminderde prestaties.

Grote en regelmatig bijgewerkte bestanden

Grote bestanden verminderen de Git-prestaties, ongeacht of ze tekst of binair zijn. De impact is het meest wanneer ze regelmatig veranderen. Omdat elke wijziging meestal een groot deel van het bestand herschrijft, wordt deltacompressie ineffectief en zorgt ervoor dat Git bijna een volledige momentopname voor elke revisie opslaat. Hierdoor groeien de grootte van de opslagplaats en het aantal objecten snel.

Aanbevolen acties

• Houd grote en regelmatig bijgewerkte bestanden uit Git. Sla ze op in Git LFS of Azure-artefacten en voer geen build-uitvoer of gegenereerde inhoud door. Zie Werken met grote bestanden in uw Git-opslagplaats voor meer informatie.
• Als een groot bestand in Git moet blijven en vaak moet worden gewijzigd, splitst u het op in kleinere logische onderdelen die onafhankelijk van elkaar kunnen worden geversied.
• Schakel het beleid Maximale bestandsgrootte in om te voorkomen dat nieuwe grote bestanden in de repository terechtkomen.

Gebruik Git LFS alleen voor grote bestanden die niet goed verschillen. Het verplaatsen van veel kleine bestanden naar LFS verbetert de prestaties niet en kan het slechter maken.

Te grote of platte mappenstructuren

Een map met veel directe items, zowel bestanden als submappen, wordt opgeslagen als één groot tree-object. Elke wijziging in het object maakt Git een nieuwe kopie van het hele object. Dit gedrag vertraagt Git-bewerkingen en verhoogt de grootte van de opslagplaats in de loop van de tijd, zelfs wanneer de wijzigingen klein zijn.

Houd het aantal directe items in één enkele map beheersbaar. Een aantal van meer dan een paar honderd is een teken dat de structuur opnieuw in balans moet worden gebracht.

Aanbevolen acties

• Items ordenen in een evenwichtige, hiërarchische indeling. Distribueer bestanden en submappen gelijkmatig zodat er geen enkele map een overmatig aantal directe vermeldingen bevat.
• Als u een grote hoeveelheid gegenereerde gegevens in de opslagplaats wilt opslaan, moet u deze partitioneren in een geneste indeling, zoals jaar/maand/dag.
• Houd gegenereerde inhoud in een consistente volgorde binnen elk bestand. Het toevoegen of verwijderen van een kleine hoeveelheid gegevens moet alleen van invloed zijn op de gerelateerde regels, niet de volgorde van de rest van het bestand wijzigen en een grote diff maken. Sorteer bijvoorbeeld altijd lijstitems op dezelfde manier.

Ongebruikte branches

Te veel langlevende, ongebruikte vertakkingen kunnen de grootte van de opslagplaats vergroten en bewerkingen vertragen. Wanneer u git clone een opslagplaats maakt, downloadt Git objecten die bereikbaar zijn vanuit elke externe vertakking, inclusief bestanden die nooit zijn samengevoegd.main

Aanbevolen acties

• Verwijder verouderde of ongebruikte vertakkingen regelmatig.
• Als uw repository terecht een zeer groot aantal branches nodig heeft, kunt u overwegen Beperkte refs in te schakelen.

Beide acties verminderen het aantal refs dat clients en de server tijdens elke fetch uitwisselen.

Klonen en ophalen versnellen

Hoe gezond een opslagplaats ook is, clients kunnen de hoeveelheid gegevens verminderen die ze downloaden:

• Een ondiepe kloon beperkt de hoeveelheid geschiedenis die wordt opgehaald, wat goed werkt in CI-omgevingen die alleen de meest recente commits nodig hebben.
• Een gedeeltelijke kloon behoudt de volledige geschiedenis, maar downloadt alleen de bestandsinhoud wanneer dat nodig is.

Zie Git Partial Clone in Azure DevOps voor meer informatie over beide opties.