リポジトリのパフォーマンスを最適化する

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

Azure Reposは、ほとんどの Git リポジトリに高いパフォーマンスと信頼性を提供します。 Git は、リポジトリが一般的なソース コード プロジェクトに似ている場合に最適に実行されます。ファイルは比較的小さく、変更は増分およびローカライズされ、ディレクトリは適切に整理された階層を持ちます。 これらの条件により、Git はデルタ圧縮を使用し、リポジトリ ツリーを効率的に走査できます。

リポジトリがこれらの条件を満たしていない場合、Git はますます大きなオブジェクトを読み取って転送する必要があります。 その結果、複製、フェッチ、参照などの一般的な操作が遅くなります。

この記事では、リポジトリの正常性を分析し、パフォーマンス低下の一般的な原因を特定して解決し、クローンとフェッチ中に転送されるデータの量を減らす方法について説明します。

リポジトリに適用されるリソース制限については、 Git の制限を参照してください。

リポジトリの正常性分析

組み込みの [正常性と使用状況 ] パネルから始めます。 リポジトリのサイズ、オブジェクト数、参照カウント、およびその他のメトリックを要約します。 また、推奨されるしきい値に近づいている、または超えている値も強調表示されます。

このパネルは、以前のバージョンのAzure DevOps Serverでは使用できない場合があります。 表示されない場合は、新しいバージョンにアップグレードして、組み込みのリポジトリの正常性メトリックにアクセスすることを検討してください。

CLI ツール

詳細な検査を行う場合は、リポジトリの完全な複製に対して次のツールを実行します。

git-sizer

リポジトリのサイズと複雑さの高レベルの評価には、 git-sizer を使用します。 リポジトリ全体のメトリックを計算し、それぞれに懸念のレベルを割り当てます。 リリース ページから最新バージョンをダウンロードし、作業の開始に従ってツールを実行し、その出力を確認します。

git リポジトリの構造

git-sizerの代わりにgit repo structureを使用します。 この実験用コマンドは、メインストリーム Git でネイティブに同様の機能を提供するように設計されています。 詳細については、 Git リポジトリのドキュメントを参照してください。

git survey

パス レベルの分析には git survey を使用します。 これらの CLI ツールのうち、最も詳細な内訳が提供されます。 オブジェクト数、オンディスクサイズ、および展開後サイズの別に、上位のディレクトリとファイルを順位付けします。 このレポートは、リポジトリ のサイズに対する最大の共同作成者を特定し、クリーンアップまたは再構築の対象にするのに役立ちます。

このコマンドは、git for Windows と Microsoft の Git フォークに含まれています。 他の Git ディストリビューションでの可用性は異なる場合があります。

Tip

リポジトリの拡張は、時間の経過と同時に解釈するのが最も簡単です。 これらのツールを定期的に実行し、結果を比較して成長傾向を追跡し、問題のあるパターンを早期に検出します。

リポジトリのパフォーマンスに関する一般的な問題と軽減策

次のパターンは、リポジトリの増加とパフォーマンス低下の最も一般的な要因です。

大きいファイルと頻繁に更新されるファイル

大きなファイルでは、テキストでもバイナリでも Git のパフォーマンスが低下します。 この影響は、頻繁に変更される場合に最も大きくなります。 通常、変更ごとにファイルの大部分が書き換えられるため、差分圧縮は無効になり、Git はリビジョンごとにほぼ完全なスナップショットを格納します。 その結果、リポジトリのサイズとオブジェクト数が急速に増加します。

  • 大規模で頻繁に更新されるファイルを Git から除外します。 Git LFS またはAzure Artifactsに格納し、ビルド出力や生成されたコンテンツをコミットしません。 詳細については、「 Git リポジトリで大きなファイルを操作する」を参照してください。
  • 大きなファイルを Git に残して頻繁に変更する必要がある場合は、個別にバージョン管理できる小さな論理部分に分割します。
  • 新しい大きなファイルがリポジトリに入るのを止めるには、 最大ファイル サイズ ポリシーを有効にします。

Git LFS は、あまり相違しない大きなファイルに対してのみ使用します。 多数の小さなファイルを LFS に移動してもパフォーマンスが向上せず、さらに悪くなる可能性があります。

特大またはフラットなディレクトリ構造

ファイルとサブディレクトリの両方の直接エントリが多数含まれるディレクトリは、1 つの大きなツリー オブジェクトとして格納されます。 その中で変更を行うと、Git はオブジェクト全体の新しいコピーを書き込みます。 この動作により、変更が小さい場合でも、Git 操作が遅くなり、リポジトリのサイズが時間の経過と伴って増加します。

管理可能な単一ディレクトリ内の直接エントリの数を保持します。 数百を超えるカウントは、構造を再調整する必要があることを示しています。

  • エントリをバランスのとれた階層型レイアウトに整理します。 どのディレクトリにも直下のエントリが過剰な数にならないように、ファイルとサブディレクトリを均等に分散します。
  • 生成された大量のデータをリポジトリに格納する必要がある場合は、 年/月/日などの入れ子になったレイアウトにパーティション分割します。
  • 生成されたコンテンツは、各ファイル内で一貫した順序で保持します。 少量のデータを追加または削除すると、関連する行にのみ影響し、ファイルの残りの部分を並べ替えたり、大きな差分を作成したりすることはできません。 たとえば、常に同じ方法でリスト アイテムを並べ替えます。

未使用のブランチ

有効期間の長すぎる未使用のブランチが多すぎると、リポジトリのサイズが大きくなり、操作が遅くなる可能性があります。 リポジトリを git clone すると、Git は、 mainにマージされなかったファイルを含め、すべてのリモート ブランチから到達可能なオブジェクトをダウンロードします。

  • 古いブランチまたは未使用のブランチを定期的に削除します。
  • リポジトリに非常に多くのブランチが正当に必要な場合は、 Limited Refs を有効にすることを検討してください。

どちらのアクションも、各フェッチ中にクライアントとサーバーがネゴシエートする ref の数を減らします。

Important

Azure Reposストレージはサーバー上の追加専用です。 この記事の推奨事項は、将来の急速な成長を防ぎますが、既に拡張されているリポジトリは縮小しません。 以前にコミットされたファイルとディレクトリは、サーバー上に残ります。 ブランチを強制的にプッシュまたは削除しても、その領域は再利用されません。 データを完全に削除する唯一の方法は、リポジトリを再作成し、必要なコンテンツのみを移行することです。

クローンとフェッチを高速化する

リポジトリがどれだけ正常であっても、クライアントはダウンロードするデータの量を減らすことができます。

  • 浅いクローンでは、フェッチされる履歴の量が制限されます。これは、最新のコミットのみを必要とする CI に適しています。
  • 部分クローンは完全な履歴を保持しますが、必要な場合にのみファイルの内容をダウンロードします。

両方のオプションの詳細については、「Azure DevOpsの Git 部分複製」を参照してください。

  • 最終更新: