リポジトリサイズ

Gitリポジトリのサイズは、パフォーマンスとストレージコストに大きく影響する可能性があります。圧縮、ハウスキーピング、その他の要因により、インスタンスごとに若干異なる場合があります。

サイズの計算

プロジェクトの概要ページには、リポジトリファイル、アーティファクト、LFSなど、リポジトリ内のすべてのファイルのサイズが表示されます。このサイズは15分ごとに更新されます。

リポジトリのサイズは、リポジトリ内のすべてのファイルの累積サイズを計算することによって決定されます。この計算は、リポジトリのハッシュ化されたストレージパスでdu --summarize --bytesを実行するのと似ています。

サイズとストレージの制限

管理者は、GitLab Self-Managedのリポジトリサイズ制限を設定できます。GitLab SaaSの場合、サイズ制限は事前定義されています。

プロジェクトがサイズ制限に達すると、プッシュ、マージリクエストの作成、LFSオブジェクトのアップロードなどの特定のオペレーションが制限されます。

リポジトリサイズを削減する方法

リポジトリのサイズを削減するには、次の方法を使用できます:

• 履歴からファイルをパージ: Gitの履歴全体から大きなファイルを削除します。
• リポジトリのクリーンアップ: 内部Git参照と参照されていないオブジェクトを削除します。
• blobを消去する: 機密情報または秘密情報を含むblobを完全に消去します。

リポジトリのサイズを小さくする前に、リポジトリの完全バックアップを作成する必要があります。これらの方法は元に戻すことができず、プロジェクトの履歴とデータに影響を与える可能性があります。

利用可能な方法でリポジトリのサイズを小さくする場合、プロジェクトへのアクセスをブロックする必要はありません。プロジェクトがユーザーにアクセス可能な状態のまま、これらのオペレーションを実行できます。これらの方法には、既知のパフォーマンスへの影響はなく、ダウンタイムも発生しません。ただし、ユーザーへの影響を最小限に抑えるために、アクティビティーの低い期間中にこれらのアクションを実行する必要があります。

リポジトリの履歴からファイルをパージ

git filter-repoを使用してファイルをパージして、Gitの履歴から大きなファイルを削除できます。パスワードやキーなどの機密データを削除するために、この方法を使用しないでください。代わりに、blobを消去するを使用してください。

このプロセス:

• Gitの履歴全体を変更します。
• オープンマージリクエストに影響を与える可能性があります。
• 既存のパイプラインに影響を与える可能性があります。
• ローカルリポジトリの再クローンが必要です。
• LFSオブジェクトには影響しません。
• コミット署名を指定しません。
• 元に戻すことはできません。

リポジトリのクリーンアップ

このメソッドを使用して、リポジトリから内部Git参照と参照されていないオブジェクトを削除します。機密データを削除するために、この方法を使用しないでください。代わりに、blobを消去するを使用してください。

このプロセス:

• git gc --prune=30.minutes.agoを実行して、参照されていないオブジェクトを削除します。
• 未使用のLFSオブジェクトのリンクを解除し、ストレージ容量を解放します。
• ディスク上のリポジトリサイズを再計算します。
• 元に戻すことはできません。

前提要件:

• 削除するオブジェクトのリスト。git filter-repoを使用して、commit-mapファイル内のオブジェクトのリストを作成します。

リポジトリをクリーンアップするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 設定 > リポジトリに移動します。

3. リポジトリの保守を展開します。

4. 削除するオブジェクトのリストをアップロードします。たとえば、filter-repoディレクトリ内のcommit-mapファイルなどです。

   commit-mapファイルが大きすぎると、バックグラウンドのクリーンアッププロセスがタイムアウトして失敗する可能性があります。その結果、リポジトリのサイズは期待どおりに縮小されません。これに対処するには、ファイルを分割して、パーツごとにアップロードします。20000から開始し、必要に応じて減らします。次に例を示します:

   split -l 20000 filter-repo/commit-map filter-repo/commit-map-

5. クリーンアップ開始を選択します。

クリーンアップが完了すると、GitLabは再計算されたリポジトリサイズを含むメール通知を送信します。

blobを消去する

Gitバイナリラージオブジェクト（blob）は、メタデータなしでファイルの内容を格納します。各blobには、リポジトリ内のファイルの特定のバージョンを表す一意のSHAハッシュがあります。

このメソッドを使用して、機密情報または秘密情報を含むblobを完全に消去します。

このプロセス:

• Gitの履歴を書き換えます。
• コミット署名をドロップします。
• 開いているマージリクエストがマージに失敗し、手動でのリベースが必要になる場合があります。
• 古いコミットSHAを参照するパイプラインが中断する可能性があります。
• 古いコミット履歴に基づいた履歴タグとブランチに影響を与える可能性があります。
• ローカルリポジトリの再クローンが必要です。
• 元に戻すことはできません。

前提要件:

• プロジェクトのオーナーのロールを持っている必要があります。
• 削除するオブジェクトIDのリスト。
• プロジェクトは以下であってはなりません:
  • パブリックアップストリームプロジェクトのフォーク。
  • ダウンストリームフォークを含むパブリックアップストリームプロジェクト。

リポジトリからblobを消去するには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > リポジトリを選択します。
3. リポジトリの保守を展開します。
4. blobを消去するするを選択します。
5. 消去するblob IDのリストを入力します。各IDは独自の行に入力します。
6. blobを消去するするを選択します。
7. 確認ダイアログで、プロジェクトパスを入力します。
8. はい、blobを消去しますを選択します。
9. 左側のサイドバーで、設定 > 一般を選択します。
10. 高度な設定というラベルが付いたセクションを展開します。
11. ハウスキーピングを実行を選択します。操作が完了するまで、少なくとも30分待ちます。
12. 同じ設定 > 一般 > 高度な設定セクションで、到達不能オブジェクトを排除するを選択します。この操作が完了するまで約5〜10分かかります。

オブジェクトIDのリストを取得する

blobを消去するには、消去するオブジェクトのリストが必要です。これらのIDを取得するには、ls-treeコマンドを使用するか、リポジトリAPIリポジトリツリーのリストエンドポイントを使用します。次の手順では、ls-treeコマンドを使用します。

前提要件:

• リポジトリをローカルマシンに複製する必要があります。

特定のコミットまたはブランチにあるblobのリストをサイズでソートして取得するには:

1. ターミナルを開き、リポジトリディレクトリに移動します。

2. 次のコマンドを実行します:

   git ls-tree -r -t --long --full-name <COMMIT/BRANCH> | sort -nk 4

   出力例:

   100644 blob 8150ee86f923548d376459b29afecbe8495514e9  133508 doc/howto/img/remote-development-new-workspace-button.png
   100644 blob cde4360b3d3ee4f4c04c998d43cfaaf586f09740  214231 doc/howto/img/dependency_proxy_macos_config_new.png
   100644 blob 2ad0e839a709e73a6174e78321e87021b20be445  216452 doc/howto/img/gdk-in-gitpod.jpg
   100644 blob 115dd03fc0828a9011f012abbc58746f7c587a05  242304 doc/howto/img/gitpod-button-repository.jpg
   100644 blob c41ebb321a6a99f68ee6c353dd0ed29f52c1dc80  491158 doc/howto/img/dependency_proxy_macos_config.png

   出力の3番目の列は、blobのオブジェクトIDです。例: 8150ee86f923548d376459b29afecbe8495514e9。

トラブルシューティング

GUIに表示されるリポジトリの統計情報が正しくない

GitLabインターフェースに表示されるリポジトリサイズまたはコミット番号が、エクスポートされた.tar.gzまたはローカルリポジトリと異なる場合は、次のようにします:

1. GitLab管理者に、Railsコンソールを使用して強制的に更新するように依頼してください。

2. 管理者は次のコマンドを実行する必要があります:

   p = Project.find_by_full_path('<namespace>/<project>')
   p.statistics.refresh!

3. プロジェクトの統計情報をクリアし、再計算をトリガーするには:

   p.repository.expire_all_method_caches
   UpdateProjectStatisticsWorker.perform_async(p.id, ["commit_count","repository_size","storage_size","lfs_objects_size","container_registry_size"])

4. アーティファクトの総ストレージスペースを確認するには:

   builds_with_artifacts = p.builds.with_downloadable_artifacts.all
   
   artifact_storage = 0
   builds_with_artifacts.find_each do |build|
     artifact_storage += build.artifacts_size
   end
   
   puts "#{artifact_storage} bytes"

クリーンアップ後にスペースが解放されない

リポジトリのクリーンアッププロセスを完了したが、ストレージの使用量が変更されない場合:

• 到達不能オブジェクトは、2週間の猶予期間リポジトリに残ることに注意してください。
• これらのオブジェクトはエクスポートには含まれませんが、ファイルシステムスペースを占有します。
• 2週間後、これらのオブジェクトは自動的に削除され、ストレージ使用量の統計が更新されます。
• このプロセスを迅速化するには、管理者に「到達不能オブジェクトの削除」ハウスキーピングタスクの実行を依頼してください。

blobが消去されない

blobが正常に消去されると、GitLabはプロジェクトの監査ログにエントリを追加し、操作を開始した人にメール通知を送信します。

blobの消去が失敗した場合、GitLabは、操作を開始した人に件名が<project_name> | Project history rewrite failureのメール通知を送信します。メール本文には、完全なエラーメッセージが含まれています。

考えられるエラーと解決策:

• validating object ID: invalid object ID:

  オブジェクトIDリストに構文エラーまたは不正なオブジェクトIDが含まれています。これを解決するには:

  1. オブジェクトIDリストを再生成します。
  2. blob消去手順を再実行します。

• source repository checksum altered:

  このエラーは、blob消去プロセス中に誰かがコミットをプッシュすると発生します。これを解決するには:

  1. リポジトリへのすべてのプッシュを一時的にブロックします。
  2. blob消去手順を再実行します。
  3. プロセスが正常に完了したら、プッシュを再度有効にします。

リポジトリのサイズ制限に達した

リポジトリのサイズ制限に達した場合:

• いくつかのデータを削除して、新しいコミットを作成してみてください。
• うまくいかない場合は、一部のblobをGit LFSに移動するか、履歴から古い依存関係更新を削除することを検討してください。
• それでも変更をプッシュできない場合は、GitLab管理者にお問い合わせいただき、一時的にプロジェクトの制限を引き上げてください。
• 最後の手段として、新しいプロジェクトを作成し、データを移行します。