git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@cam.org>
To: Hin-Tak Leung <hintak.leung@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git gc expanding packed data?
Date: Wed, 12 Aug 2009 11:35:24 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0908121118420.10633@xanadu.home> (raw)
In-Reply-To: <3ace41890908120745y305b2a59hd453b7e146e4a774@mail.gmail.com>

On Wed, 12 Aug 2009, Hin-Tak Leung wrote:

> On Tue, Aug 11, 2009 at 10:33 PM, Nicolas Pitre<nico@cam.org> wrote:
> <snipped>
> 
> > From git v1.6.3 the --aggressive switch makes for 'git repack' to be
> > called with --window=250 --depth=250, meaning the equivalent of:
> >
> >        git repack -a -d -f --window=250 --depth=250
> >
> > Do you still get a huge pack with the above?
> >
> >> I guess --aggressive doesn't always save space...
> >
> > If so that is (and was) a bug.
> 
> I tried 'git repack -a -d -f --window=250 --depth=250' with 1.6.2.5
> (fc11.x86_64) and it took half a day, swallowed up all the memory -
> 3GB virtual & 1.3GB resident - and finally the kernel oom killer
> killed it at a last message of (601460/957910). Left no temp files.
> Would git 1.6.3 use less memory? :-(

Probably not.  However you should try:

	git config pack.deltaCacheSize 1

That limits the delta cache size to one byte (effectively disabling it) 
instead of the default of 0 which means unlimited.  With that I'm able 
to repack that repository using the above git repack command on an 
x86-64 system with 4GB of RAM and using 4 threads (this is a quad core).  
Resident memory usage grows to nearly 3.3GB though.

If your machine is SMP and you don't have sufficient RAM then you can 
reduce the number of threads to only one:

	git config pack.threads 1

Additionally, you can further limit memory usage with the 
--window-memory argument to 'git repack'.  For example, using 
--window-memory=128M should keep a reasonable upper bound on the delta 
search memory usage although this can result in less optimal delta match 
if the repo contains lots of large files (and I think this is the case 
for the gcc repo).


Nicolas

  reply	other threads:[~2009-08-12 15:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04 20:25 git gc expanding packed data? Hin-Tak Leung
2009-08-05 22:39 ` Nicolas Pitre
2009-08-11 10:17   ` Hin-Tak Leung
2009-08-11 21:33     ` Nicolas Pitre
2009-08-12 14:45       ` Hin-Tak Leung
2009-08-12 15:35         ` Nicolas Pitre [this message]
2009-08-13 17:31           ` Hin-Tak Leung
  -- strict thread matches above, loose matches on Subject: below --
2009-08-08  1:11 Andreas Schwab
2009-08-08 13:05 ` Hin-Tak Leung
2009-08-08 13:25   ` Andreas Schwab
2009-08-09  2:56 ` Nicolas Pitre
2009-08-09  7:43   ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.0908121118420.10633@xanadu.home \
    --to=nico@cam.org \
    --cc=git@vger.kernel.org \
    --cc=hintak.leung@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).