共有ホストでgitリポジトリをホストしています。私のリポジトリには必然的に非常に大きなファイルがいくつかあり、リポジトリで「git gc」を実行しようとするたびに、メモリを使いすぎたために共有ホスティングプロバイダーによってプロセスが強制終了されます。 git gcが消費できるメモリの量を制限する方法はありますか?私の望みは、メモリ使用量と速度を交換し、作業に少し時間がかかることです。
はい、git config
のヘルプページをご覧になり、pack.*
オプション、具体的にはpack.depth
、pack.window
、pack.windowMemory
、pack.deltaCacheSize
をご覧ください。 。
Gitは各オブジェクトをメモリにマッピングする必要があるため、完全に正確なサイズではありません。そのため、1つの非常に大きなオブジェクトは、ウィンドウとデルタキャッシュの設定に関係なく、多くのメモリ使用量を引き起こす可能性があります。
ローカルでパックし、パックファイルを「手動で」リモート側に転送して.keep
ファイルを追加すると、リモートgitがすべてを完全に再パックしようとしないようにすることができます。
私はこれからの指示を使用しました リンク 。 Charles Baileys と同じ考えが提案されました。
コマンドのコピーはここにあります:
git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"
これは、共有ホスティングアカウントを持つhostgatorで私のために働きました。
Gitrepackのメモリ使用量は(pack.deltaCacheSize + pack.windowMemory) × pack.threads
です。それぞれのデフォルトは256MiB、無制限、nprocです。
デルタキャッシュは役に立ちません。ほとんどの時間はスライディングウィンドウでデルタを計算するために費やされ、その大部分は破棄されます。サバイバーをキャッシュして、一度(書き込み時に)再利用できるようにしても、ランタイムは改善されません。そのキャッシュもスレッド間で共有されません。
デフォルトでは、ウィンドウメモリはpack.window
(gc.aggressiveWindow
)によって制限されています。ワーキングセットのサイズと効率は大きく異なるため、このようにパッキングを制限することはお勧めできません。両方をはるかに高い値に上げ、pack.windowMemory
を使用してウィンドウサイズを制限することをお勧めします。
最後に、スレッド化には、ワーキングセットを分割するという欠点があります。合計が同じになるようにpack.threads
を下げてpack.windowMemory
を上げると、実行時間が改善されます。
repackには他にも便利な調整機能(pack.depth
、pack.compression
、ビットマップオプション)がありますが、メモリ使用量には影響しません。
デルタ属性をオフにして、これらのパス名のBLOBのみのデルタ圧縮を無効にすることができます。
foo/.git/info/attributes
(またはベアリポジトリの場合はfoo.git/info/attributes
)(パターン構文については gitattributes のデルタエントリを参照し、 gitignore を参照):
/large_file_dir/* -delta
*.psd -delta
/data/*.iso -delta
/some/big/file -delta
another/file/that/is/large -delta
これは、リポジトリのクローンには影響しません。他のリポジトリ(つまり、クローン)に影響を与えるには、属性を.gitattributes
ファイルの代わりに(またはそれに加えて)info/attributes
ファイルに配置します。