Re: Git exhausts memory.

From: David Fries <david@fries.net>
Date: Apr 5, 2011, 02:22 UTC
Message-ID: <20110405022235.GA4414@spacedout.fries.net>
In-Reply-To: <BANLkTinU7x16yp+y-HW9UhkVn9SftOJCcA@mail.gmail.com>

On Mon, Apr 04, 2011 at 09:57:01PM +0700, Nguyen Thai Ngoc Duy wrote:

Show 12 quoted lines

> On Mon, Apr 4, 2011 at 7:52 PM, Alif Wahid <alif.wahid@gmail.com> wrote:
> > Hi Nicolas,
> >
> > On 4 April 2011 01:18, Nicolas Pitre <nico@fluxnic.net> wrote:
> >>
> >> Something you can try is to simply tell Git not to attempt any delta
> >> compression on those tar files using gitattributes (see the man page of
> >> the same name).
> 
> Should we change the default to not delta if a blob exceeds predefined
> limit (say 128M)? People who deliberately wants to delta them can
> still set delta attr. 1.8.0 material maybe?

I think it would be better to define it in terms of available memory. Something like the minimum of system memory or address space, and delta up to X amount of that (it might be good to leave off swap to reduce trashing). There has to be a better way than a straight 128MB default.

The number which works on my 8GB desktop is going to kill the computer in the trunk of my car with 48MB of ram. I've actually seen a 700 MB repository fail with `git-gc --aggressive` on a system with 4GB of ram because it ran out of memory, it only worked by leaving off the --aggressive option.

Show 10 quoted lines

> > Seems to have worked. Both git-gc and git-repack appear to be less
> > memory hungry now and do actually run to completion without failure.
> >
> > Thanks for your help.
> -- 
> Duy
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
David Fries <david@fries.net>    PGP pub CB1EE8F0
http://fries.net/~david/