ソースコードとバイナリの両方を含むgitリポジトリがあります。ベアリポジトリは現在約9GBに達しており、クローン作成には何年もかかります。ほとんどの時間は「リモート：オブジェクトの圧縮」に費やされます。大きなバイナリの1つの新しいバージョンでコミットした後、フェッチには長い時間がかかり、サーバー上のオブジェクトの圧縮にも費やされます。
オブジェクトをリモートで圧縮せずにgitpullを読んだ後、バイナリファイルのデルタ圧縮も私たちを傷つけているのではないかと思いますが、これを修正する方法が100％わかりません。
サーバー上のベアリポジトリを修正するための正確な手順は何ですか？私の推測：
- 必要なすべての拡張子の「*.zip-delta」のようなエントリを.git/info/attributesに追加します
- 'git repack'を実行しますが、どのようなオプションがありますか？-adFはすべてを再パックし、指定されたファイルタイプでデルタ圧縮が行われたことがないリポジトリを残しますか？
- 'gitprune'を実行します。これは自動的に行われると思いましたが、上記のリポジトリの裸のクローンで遊んだときに実行すると、サイズが最大2GB減少しました
- リポジトリのクローンを作成し、ベアリポジトリの.git / info/attributesに追加したのと同じエントリで.gitattributesを追加してコミットします
私は何かに取り組んでいますか？
アップデート：
これに関するいくつかの興味深いテスト結果。今日、私は問題のあるリポジトリのベアクローンを開始しました。4GBのRAMを搭載したそれほど強力ではないサーバーがメモリを使い果たし、スワッピングを開始しました。3時間後に私はあきらめました...
次に、代わりに、最新の作業コピーからベアリポジトリのクローンを作成しました。ワークステーション間でのクローン作成には約5分かかりました。次に、それを新しいリポジトリとしてサーバーにプッシュしました。そのレポのクローン作成には7分しかかかりませんでした。
これを正しく解釈すると、バイナリファイルのデルタ圧縮を無効にしなくても、パックされたリポジトリのパフォーマンスが大幅に向上します。これは、上記の手順が実際に短期的にやりたいことであることを意味していると思いますが、それに加えて、サーバーでのパッキング/圧縮に使用できるメモリの量を制限する方法を見つける必要があります。スワッピング。
重要な場合：サーバーはgit 1.7.0.4を実行し、ワークステーションは1.7.9.5を実行します。
アップデート2：
私は自分のtestrepoで次の手順を実行しましたが、サーバーで実行する可能性があると思います（バックアップ後）
オブジェクトをパックするときのメモリ使用量を制限する
git config pack.windowMemory 100m
git config pack.packSizeLimit 200m一部の拡張機能のデルタ圧縮を無効にする
echo'* .tar.gz -delta' >> info / attributes
echo'* .tar.bz2 -delta' >> info / attributes
echo'* .bin -delta' >> info / attributes
echo'* .png -delta '>>情報/属性リポジトリを再パックしてゴミを収集する
git repack -a -d -F --window-memory 100m --max-pack-size 200m
git gc
アップデート3：
この操作後のいくつかの予期しない副作用：パフォーマンスを向上させるためにgitリポジトリを再パックしようとした後の問題