How to perform manual garbage collection on a repository in Bitbucket Server
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Fisheye および Crucible は除く
目的
このページでは、Bitbucket にガベージ コレクションを実行させるために必要な手順を網羅しています。
Bitbucket runs garbage collection when needed; to avoid data loss, this should never be performed manually on the repositories.
The best course of action is to allow Bitbucket to run it instead of running it manually.
ソリューション
Bitbucket 5+
Bitbucket implements its own garbage collection logic without relying on git gc anymore (this is achieved by setting the [gc] auto = 0 on all repositories). When a fork is created, the pruneexpire=never is added to the git configuration and this is removed when the last fork is deleted.
Bitbucket < 5.0
Bitbucket サービスはプッシュ時に git によって行われる自動 gc に依存します。これは git gc が確実に実行されるのを意味するわけではありません。git は gc が必要かどうかを判断するための発見的アルゴリズムを備えています (リポジトリに 6700 個の緩いオブジェクトまたは 50 個の pack ファイルがある。緩いオブジェクトの数は objects/17 に含まれるオブジェクトの数を数えることで見積もられます)。
For repositories with forks, the git auto garbage collection is disabled by setting the gc.auto 0
configuration option as soon as the first fork is created. This setting is then removed, re-enabling the auto gc as soon as the last fork is removed.
追加情報
フォークの存在を確認
ガベージ コレクションは (必要なデータが失われるのを防ぐために) フォークがない場合にのみ実行できるため、リポジトリにフォークがあるかどうかを最初に確認する必要があります。
これは次の REST API を実行することで確認できます (ドキュメントはこちら)。
curl --user <username>:<password> -H "Content-Type: application/json" -X GET <bitbucket_url>/rest/api/1.0/projects/<project_key>/repos/<repository_slug>/forks > ./rest_output.txt
リポジトリにフォークがない場合は次のような結果が返されます。
{"size":0,"limit":25,"isLastPage":true,"values":[],"start":0}
リポジトリにフォークがある場合、データ損失を防ぐため、ガベージ コレクション (git gc または git prune) を行うべきではありません。
フォークを取り除けないが repack を実行したい場合
In production, the following steps can require some time. For this reason, it is recommended to check the potential gain on a copy of the repository first.
Also keep track of the time required to perform the full sequence of steps as the user that runs the Bitbucket process.
cd <repository path in the Bitbucket home directory>
cp -r * some/tmp/location
cd some/tmp/location
du -h
git fsck
git repack -adfln --keep-unreachable --depth=20 --window=200
du -h
効果が大きい場合、必要なダウンタイムを計画して次の手順に進みます。
効果を確認するための別の方法として、repack の前後に次のコマンドを実行する方法があります。
git count-objects -v
リポジトリ自体で repack を実行する
- Bitbucket Server のバックアップを生成します ( 「データの復元とバックアップ」)。
- Stop Bitbucket Server
Run the following commands as the user that runs the Bitbucket process:
cd <repository path in the Bitbucket home directory> du -h git fsck git repack -adfln --keep-unreachable --depth=20 --window=200 du -h
- Start Bitbucket Server
The fsck command sees the status of the source repository. It checks for file consistency and integrity in the system and outputs the results.
The repack command will clean up loose objects and compact the data.
本番環境で repack を実行する前にインスタンスを停止できない場合は次の手順を実行します。
これにより、Bitbucket Server が repack 中に repack を試行するのを防ぐことができます。