Optymalizowanie wydajności repozytorium

Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Azure Repos zapewnia wysoką wydajność i niezawodność większości repozytoriów Git. Usługa Git sprawdza się najlepiej, gdy repozytoria przypominają typowe projekty kodu źródłowego: pliki są stosunkowo małe, zmiany są przyrostowe i zlokalizowane, a katalogi mają dobrze zorganizowaną hierarchię. Te warunki umożliwiają usłudze Git efektywne korzystanie z kompresji różnicowej i przechodzenie drzew repozytorium.

Gdy repozytorium nie spełnia tych warunków, usługa Git musi odczytywać i przesyłać więcej i większych obiektów. W związku z tym typowe operacje, takie jak klonowanie, pobieranie i przeglądanie, stają się wolniejsze.

W tym artykule wyjaśniono, jak analizować kondycję repozytorium, identyfikować i rozwiązywać typowe przyczyny obniżenia wydajności oraz zmniejszać ilość danych przesyłanych podczas klonów i pobierania.

Aby uzyskać limity zasobów, które mają zastosowanie do repozytoriów, zobacz Limity usługi Git.

Analiza kondycji repozytorium

Zacznij od wbudowanego panelu Kondycja i użycie . Zawiera podsumowanie rozmiaru repozytorium, liczby obiektów, liczby odwołań i innych metryk. Wyróżnia również wartości zbliżające się lub przekraczające zalecane progi.

Ten panel może nie być dostępny w starszych wersjach Azure DevOps Server. Jeśli go nie widzisz, rozważ uaktualnienie do nowszej wersji, aby uzyskać dostęp do wbudowanych metryk kondycji repozytorium.

Narzędzia interfejsu wiersza polecenia

Aby dokładniej to sprawdzić, uruchom następujące narzędzia na pełnej kopii repozytorium.

git-sizer

Użyj git-sizer, aby uzyskać ogólną ocenę rozmiaru i złożoności repozytorium. Oblicza ona metryki obejmujące całe repozytorium i przypisuje poziom obaw do każdego z nich. Pobierz najnowszą wersję ze strony wydań i postępuj zgodnie z instrukcjami Wprowadzenie , aby uruchomić narzędzie i przejrzeć jego dane wyjściowe.

struktura repozytorium git

Użyj git repo structure jako alternatywy dla git-sizer. To eksperymentalne polecenie zostało zaprojektowane tak, aby zapewnić podobne funkcje natywnie w głównym środowisku Git. Aby uzyskać więcej informacji, zobacz dokumentację repozytorium Git.

ankieta usługi git

Użyj git survey do analizy na poziomie ścieżki. Spośród tych narzędzi CLI to zapewnia najbardziej szczegółowy podział. Klasyfikuje on najwyższe katalogi i pliki według liczby obiektów, rozmiaru dysku i zawyżonego rozmiaru. Raport pomaga zidentyfikować elementy mające największy udział w rozmiarze repozytorium i wytypować je do czyszczenia lub restrukturyzacji.

To polecenie wchodzi w skład Git for Windows oraz forku Git firmy Microsoft. Dostępność w innych dystrybucjach Usługi Git może się różnić.

Tip

Przyrost repozytorium najłatwiej interpretować w miarę upływu czasu. Okresowo uruchamiaj te narzędzia i porównuj wyniki w celu śledzenia trendów wzrostu i wczesnego wykrywania problematycznych wzorców.

Typowe problemy z wydajnością repozytorium i środki zaradcze

Poniższe wzorce najczęściej przyczyniają się do rozrostu repozytorium i pogorszenia wydajności.

Duże i często aktualizowane pliki

Duże pliki zmniejszają wydajność usługi Git niezależnie od tego, czy są to pliki tekstowe, czy binarne. Wpływ jest największy, gdy często się zmieniają. Ponieważ każda zmiana zwykle ponownie zapisuje dużą część pliku, kompresja różnicowa staje się nieskuteczna i powoduje, że usługa Git przechowuje niemal pełną migawkę dla każdej poprawki. W związku z tym rozmiar repozytorium i liczba obiektów szybko rosną.

  • Zachowaj duże i często aktualizowane pliki poza usługą Git. Przechowuj je w usłudze Git LFS lub Azure Artifacts i nie zatwierdzaj danych wyjściowych kompilacji ani wygenerowanej zawartości. Aby uzyskać więcej informacji, zobacz Praca z dużymi plikami w repozytorium Git.
  • Jeśli duży plik musi pozostać w usłudze Git i często się zmienia, należy podzielić go na mniejsze elementy logiczne, które mogą być wersjonowane niezależnie.
  • Aby zatrzymać wprowadzanie nowych dużych plików do repozytorium, włącz zasady Maksymalny rozmiar pliku .

Używaj usługi Git LFS tylko w przypadku dużych plików, które nie różnicują się dobrze. Przeniesienie wielu małych plików do LFS nie poprawia wydajności i może pogorszyć jego wydajność.

Ponadwymiarowe lub płaskie struktury katalogów

Katalog z wieloma bezpośrednimi wpisami, zarówno plikami, jak i podkatalogami, jest przechowywany jako jeden duży obiekt drzewa. Każda zmiana w nim powoduje, że usługa Git napisze nową kopię całego obiektu. To zachowanie spowalnia operacje git i zwiększa rozmiar repozytorium w czasie, nawet jeśli zmiany są małe.

Utrzymuj liczbę bezpośrednich elementów w każdym katalogu na rozsądnym poziomie. Liczba powyżej kilkuset jest znakiem, że struktura powinna zostać ponownie zrównoważona.

  • Organizowanie wpisów w zrównoważonym, hierarchicznym układzie. Równomierne dystrybuowanie plików i podkatalogów, tak aby żaden pojedynczy katalog nie zawierał nadmiernej liczby wpisów bezpośrednich.
  • Jeśli musisz przechowywać dużą ilość wygenerowanych danych w repozytorium, podziel je na zagnieżdżony układ, taki jak rok/miesiąc/dzień.
  • Zachowaj wygenerowaną zawartość w spójnej kolejności w ramach każdego pliku. Dodawanie lub usuwanie niewielkiej ilości danych powinno mieć wpływ tylko na powiązane wiersze, a nie zmianę kolejności pozostałej części pliku i utworzenie dużej różnicy. Na przykład zawsze sortuj elementy listy w taki sam sposób.

Nieużywane gałęzie

Zbyt wiele długo istniejących, nieużywanych gałęzi może zwiększyć rozmiar repozytorium i spowolnić operacje. W przypadku git clone repozytorium usługa Git pobiera obiekty dostępne z każdej gałęzi zdalnej, w tym pliki, które nigdy nie zostały scalone z usługą main.

  • Regularnie usuwaj nieaktywne lub nieużywane gałęzie.
  • Jeśli repozytorium rzeczywiście wymaga bardzo dużej liczby gałęzi, rozważ włączenie funkcji Limited Refs.

Obie akcje zmniejszają liczbę ref, które klienci i serwer negocjują podczas każdego pobierania.

Ważna

Magazyn danych usługi Azure Repos na serwerze obsługuje wyłącznie dopisywanie. Zalecenia zawarte w tym artykule uniemożliwiają szybki wzrost w przyszłości, ale nie zmniejszają repozytorium, które już się rozwinęło. Wcześniej zatwierdzone pliki i katalogi pozostają na serwerze. Wymuszone wypchnięcie lub usunięcie gałęzi nie odzyskuje tej przestrzeni. Jedynym sposobem całkowitego usunięcia danych jest ponowne utworzenie repozytorium i zmigrowanie tylko potrzebnej zawartości.

Przyspiesz klonowanie i pobieranie

Niezależnie od kondycji repozytorium klienci mogą zmniejszyć ilość pobieranych danych:

  • Płytkie klonowanie ogranicza zakres pobieranej historii, co dobrze sprawdza się w CI, które wymaga tylko najnowszych commitów.
  • Klon częściowy zachowuje pełną historię, ale pobiera zawartość pliku tylko wtedy, gdy jest to konieczne.

Aby uzyskać więcej informacji na temat obu opcji, zobacz Git Partial Clone w Azure DevOps.

  • Last updated on