まとめ
Gitのremote通信が重くなって困っていたのですが
repositoryを新規作成して、コピーしてから元のrepositoryと名前を差し替えると
劇的に軽くなり、repository利用者側での再取得も不要でした。
2019/8/24追記
BitBucketのバグで、pull-requestをdeleteした場合に場合に参照が残り続けてしまう、というのが原因でした。
リモート側リポジトリに残っている参照情報を消す権限があればそれだけで解決します。
修正後のBitBucketバージョンであれば新規に発生はしませんが、過去に消しそびれた参照情報は残り続けるようです。
https://jira.atlassian.com/browse/BSERV-10708
背景
BitBucketをJira, Confluenceと連携して、git-flowで運用しています。
運用4年ほどで20,000 commitに8000 pull-request程度。
最近重くなって来ており、fetchで10秒かかることもあったので調査することにしました。
原因の切り分け
- git commitやgit log、その他ローカルで完結する作業は問題無し
- git fetch、push、その他remote通信する作業は重い
- git gc --aggressive 目に見える効果無し
- git prune 普段からやっているので当然効果無し
- 新規pull-request作成時、branch候補の表示が重いが、少しでも絞り込むと軽い
- 同じプロジェクトの別のrepositoryは、remote通信も軽い
アプローチ
とりあえずネットワークの問題ではなさそうと判断し
正攻法のsub module化、あるいは大きめファイルのgit-filter削除を検討。
検証用repositoryを作成し、既存repositoryのremoteを切り替えてpushしたところ圧倒的に早い！
移行実施
- 関係者にremote repositoryを触らないように連絡
- pull-requestを全部消化
- 不要なremote branchがあれば削除
- 移行先repositoryを作成
- atlassianの手順通りにコピー
- 移行元repositoryの名前をバックアップ用に変更
- 移行先repositoryを移行元repositoryの元の名前に変更
- 関係者に解禁のお知らせ出して終わり
速度変化
git fetch(2回目): 0m13.386s -> 0m0.400s
git push(新規ファイル追加その１): 0m27.705s -> 0m0.749s
git push(新規ファイル追加その２): 0m40.340s -> 0m0.983s
注意点
pull-requestは移行できませんでした。
JIRAからの参照時、旧repositoryを残しておけばそちらへのpull-requestの参照は残りますが、
逆にcommitへの参照は二重に残ってしまいます。
また、早くなった原因が不明です。
推測としてはremote側のrepositoryに何かしらのゴミが溜まってる、
あるいはpull-request自体が非常に重い、のどちらかだとは思うのですが。
あやふやで恐縮ですが、何かのお役に立てば幸いです。