Azure DevOps の目標は、すべてのお客様に優れた品質のサービスを提供することです。 パフォーマンスと信頼性を確保するうえで、リポジトリの最適な正常性を維持することが非常に重要になります。
この目標を推進するには、リポジトリの正常性に関わるさまざまな要素を積極的に監視します。 このような要素には、サイズ、コミット頻度、コンテンツ、構造などが含まれます。 お使いのリポジトリが Microsoft のインフラストラクチャに過度に影響する場合は、是正措置をお願いするメールをサポート チームから送らせていただく場合があります。 リポジトリのサイズと全体的な正常性を効果的に管理すれば、インフラストラクチャとパフォーマンスへのマイナスの影響を回避できます。
リポジトリの正常性を最適に保つには、[リポジトリの正常性と使用状況] パネルを使用します。
Web ブラウザーから、Azure Repos Git リポジトリに移動します。 [リポジトリ] > [ファイル] を選択し、省略記号メニューから [正常性と使用状況] を選択して、[リポジトリの正常性と使用状況] パネルを開きます。
[リポジトリの正常性と使用状況] パネルには、リポジトリの正常性に関わる要素が表示されます
異常と見なされる要素は赤色で強調表示され、異常に近い要素は黄色で強調表示されます。
このページでは、一般的なメトリックに関する説明とアドバイスを掲載しています。
リポジトリ全体の上限サイズ
このパラメーターは、リポジトリがディスク上で消費する容量を示します。
最適なパフォーマンスを得るには、リポジトリのサイズを 100 GB 未満にすることをお勧めします。 リポジトリが小さいほど、クローン作成が速く、管理やメンテナンスが容易になります。 リポジトリがこのサイズを超える場合は、Git-LFS、Scalar、または Azure Artifacts を使用して開発成果物のリファクタリングを行うことを検討してください。
オブジェクト数の上限
このパラメーターは、任意の参照またはタグからアクセスできる、リポジトリ内のオブジェクト数を示します。 オブジェクトには、ファイル (BLOB) だけでなく、ディレクトリ、コミット、タグも含まれます。 詳細については、Git-Internals-Git-Objects を参照してください。
オブジェクトの数が多くなるほど、Git がリポジトリの履歴を走査するためにかかる時間が長くなり、コミットやその他のオブジェクトの履歴が表示されるまでの時間に影響します。 さらに、ADO の実装では、オブジェクト数がハード リミットによって制限されています。 Azure Repos では、1 つのリポジトリに 1 億を超える数のオブジェクトを含めることはできません。
参照の数
[参照の数] は、リポジトリ内の参照の合計数を示します。
Git リポジトリに 10,000 を超える参照が含まれている場合は、[参照の制限] を有効にすることを検討してください。 参照の数が増加すると、クライアントとサーバーの間でのネゴシエートを要するデータも増加します。 ネゴシエートを要するデータが増加するほど、サーバーの負荷が大きく、クライアントに転送される可能性のあるデータ量も多くなり、ユーザー エクスペリエンスの低下につながります。
BLOB 数の上限
[BLOB 数の上限] は、リポジトリ内で到達可能な BLOB ファイルの合計数を示します。
Number of reachable objects で説明したように、適切な BLOB ファイル数を維持することをお勧めします。 他の型のオブジェクト用に容量を確保しておくことも重要です。
ツリー数の上限
[ツリー数の上限] は、リポジトリ内で到達可能な tree オブジェクトの合計数を示します。
ツリー ファイルの数が多すぎると、履歴を走査するコストが高くなり、git blame などの git 機能で速度が低下する可能性があります。
ディレクトリとファイルの数が増えると、tree オブジェクトが増加します。 Git では、ファイルが変更されるたびに、そのファイルにつながるすべてのツリーのコピーを作成する必要があります。 このため、1 つのファイルのみを複数回変更した場合も、多数のツリー ファイルが発生する可能性があります。
Note
単一のディレクトリに多数の直接エントリを配置するよりも、複数のディレクトリとサブディレクトリにファイルを分散することをお勧めします。
Number of reachable objects のセクションで推奨されているように、適切な tree オブジェクト数を維持することをお勧めします。 また、他の型のオブジェクト用に容量を割り当てることも重要です。
コミット数の上限
[コミット数の上限] パラメーターは、リポジトリ内で到達可能な commit オブジェクトの合計数を表します。
Number of reachable objects セクションで説明されているように、適切な commit オブジェクト数を維持することをお勧めします。 他の型のオブジェクト用に容量を確保しておくことも必要です。
タグ数の上限
[タグ数の上限] は、リポジトリ内で到達可能な tag オブジェクトの合計数を示します。
タグは、フェッチが発生するたびにクライアントに転送する必要があります。クローンが最新であっても同じです。 このため、最大でも数万個程度に制限することをお勧めします。
Number of reachable objects セクションで説明されているように、適切な tag オブジェクト数を維持することをお勧めします。 他の型のオブジェクト用に容量を確保しておくことも必要です。
差分確認できないファイルの数
差分を計算できなかったバイナリ ファイルまたはメディア アセットの数を示します。
このようなファイルを Git に格納することはお勧めしません。 このようなファイルに異なるバージョンが存在する場合、これらの差分を正常に確認できないため、Git で効率的に保存できません。 このようなファイルを保存したうえで、リポジトリの正常性と保守可能な状態を維持するには、Git-LFS、Scalar、または Azure Artifacts の使用を検討してください。 詳細については、「Git で大きなファイルを管理および格納する」を参照してください。
Note
REST Pushes API の使用では、ファイルの差分を確認できないため、通常であれば差分の確認が可能なオブジェクトのプッシュがきわめて非効率的になります。
上限 BLOB サイズ
[上限 BLOB サイズ] パラメーターは、ディスク上の BLOB の合計サイズをギガバイト単位で示します。
[リポジトリ全体の上限サイズ] の説明に従い、この値を 100 GB 未満にして、他の型のオブジェクト用に容量を残しておくことをお勧めします。
上限ツリー サイズ
[上限ツリー サイズ] パラメーターは、ディスク上の tree オブジェクトの合計サイズをギガバイト単位で示します。
[リポジトリ全体の上限サイズ] の説明に従い、この値を 100 GB 未満にして、他の型のオブジェクト用に容量を残しておくことをお勧めします。
上限コミット サイズ
[上限コミット サイズ] パラメーターは、ディスク上の commit オブジェクトの合計サイズをメガバイト単位で示します。
[リポジトリ全体の上限サイズ] の説明に従い、この値を 100 GB 未満にして、他の型のオブジェクト用に容量を残しておくことをお勧めします。
上限タグ サイズ
[上限タグ サイズ] パラメーターは、ディスク上の tag オブジェクトの合計サイズをギガバイト単位で示します。
[リポジトリ全体の上限サイズ] の説明に従い、この値を 100 GB 未満にして、他の型のオブジェクト用に容量を残しておくことをお勧めします。