I'm hosting a git repo on a shared host. My repo necessarily has a couple of very large files in it, and every time I try to run "git gc" on the repo now, my process gets killed by the shared hosting provider for using too much memory. Is there a way to limit the amount of memory that git gc can consume? My hope would be that it can trade memory usage for speed and just take a little longer to do its work.
相关问题
- What uses more memory in c++? An 2 ints or 2 funct
- Memory for python.exe on Windows 7 python 32 - Num
- Why does recursive submodule update from github fa
- Extended message for commit via Visual Studio Code
- Emacs shell: save commit message
相关文章
- 请教Git如何克隆本地库?
- Why are memory addresses incremented by 4 in MIPS?
- GitHub:Enterprise post-receive hook
- Git Clone Fails: Server Certificate Verification F
- SSIS solution on GIT?
- Is there a version control system abstraction for
- ssh: Could not resolve hostname git: Name or servi
- Cannot commit changes with gitextensions
I used instructions from this link. Same idea as Charles Baileys suggested.
A copy of the commands is here:
This worked for me on hostgator with shared hosting account.
Git repack's memory use is:
(pack.deltaCacheSize + pack.windowMemory) × pack.threads
. Respective defaults are 256MiB, unlimited, nproc.The delta cache isn't useful: most of the time is spent computing deltas on a sliding window, the majority of which are discarded; caching the survivors so they can be reused once (when writing) won't improve the runtime. That cache also isn't shared between threads.
By default the window memory is limited through
pack.window
(gc.aggressiveWindow
). Limiting packing that way is a bad idea, because the working set size and efficiency will vary widely. It's best to raise both to much higher values and rely onpack.windowMemory
to limit the window size.Finally, threading has the disadvantage of splitting the working set. Lowering
pack.threads
and increasingpack.windowMemory
so that the total stays the same should improve the run time.repack has other useful tunables (
pack.depth
,pack.compression
, the bitmap options), but they don't affect memory use.Git 2.18 (Q2 2018) will improve the gc memory consumption.
Before 2.18, "
git pack-objects
" needs to allocate tons of "struct object_entry
" while doing its work: shrinking its size helps the performance quite a bit.This influences
git gc
.See commit f6a5576, commit 3b13a5f, commit 0aca34e, commit ac77d0c, commit 27a7d06, commit 660b373, commit 0cb3c14, commit 898eba5, commit 43fa44f, commit 06af3bb, commit b5c0cbd, commit 0c6804a, commit fd9b1ba, commit 8d6ccce, commit 4c2db93 (14 Apr 2018) by Nguyễn Thái Ngọc Duy (
pclouds
).(Merged by Junio C Hamano --
gitster
-- in commit ad635e8, 23 May 2018)With Git 2.20 (Q4 2018), it will be easier to check an object that exists in one fork is not made into a delta against another object that does not appear in the same forked repository.
See commit fe0ac2f, commit 108f530, commit f64ba53 (16 Aug 2018) by Christian Couder (
chriscool
).Helped-by: Jeff King (
peff
), and Duy Nguyen (pclouds
).See commit 9eb0986, commit 16d75fa, commit 28b8a73, commit c8d521f (16 Aug 2018) by Jeff King (
peff
).Helped-by: Jeff King (
peff
), and Duy Nguyen (pclouds
).(Merged by Junio C Hamano --
gitster
-- in commit f3504ea, 17 Sep 2018)Yes, have a look at the help page for
git config
and look at thepack.*
options, specificallypack.depth
,pack.window
,pack.windowMemory
andpack.deltaCacheSize
.It's not a totally exact size as git needs to map each object into memory so one very large object can cause a lot of memory usage regardless of the window and delta cache settings.
You may have better luck packing locally and transfering pack files to the remote side "manually", adding a
.keep
files so that the remote git doesn't ever try to completely repack everything.You could use turn off the delta attribute to disable delta compression for just the blobs of those pathnames:
In
foo/.git/info/attributes
(orfoo.git/info/attributes
if it is a bare repository) (see the delta entry in gitattributes and see gitignore for the pattern syntax):This will not affect clones of the repository. To affect other repositories (i.e. clones), put the attributes in a
.gitattributes
file instead of (or in addition to) theinfo/attributes
file.