From: David Fries <david@fries.net>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Nicolas Pitre <nico@fluxnic.net>,
Git Mailing List <git@vger.kernel.org>,
Alif Wahid <alif.wahid@gmail.com>
Subject: Re: Git exhausts memory.
Date: Mon, 4 Apr 2011 21:22:35 -0500 [thread overview]
Message-ID: <20110405022235.GA4414@spacedout.fries.net> (raw)
In-Reply-To: <BANLkTinU7x16yp+y-HW9UhkVn9SftOJCcA@mail.gmail.com>
On Mon, Apr 04, 2011 at 09:57:01PM +0700, Nguyen Thai Ngoc Duy wrote:
> 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.
> > 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/
next prev parent reply other threads:[~2011-04-05 2:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-02 5:01 Git exhausts memory Alif Wahid
2011-04-02 15:05 ` Nicolas Pitre
2011-04-03 9:15 ` Alif Wahid
2011-04-03 15:18 ` Nicolas Pitre
2011-04-04 12:52 ` Alif Wahid
2011-04-04 14:57 ` Nguyen Thai Ngoc Duy
2011-04-05 2:22 ` David Fries [this message]
2011-04-05 4:35 ` Alif Wahid
2011-04-05 11:13 ` Nguyen Thai Ngoc Duy
2011-04-05 11:26 ` Alif Wahid
2011-04-05 16:48 ` Holger Hellmuth
2011-04-05 17:06 ` Shawn Pearce
2011-04-05 17:44 ` Junio C Hamano
2011-04-05 20:56 ` Nicolas Pitre
2011-04-05 22:16 ` Junio C Hamano
2011-04-05 22:19 ` Shawn Pearce
2011-04-06 0:34 ` Nicolas Pitre
2011-04-06 15:51 ` Jay Soffian
2011-04-06 16:33 ` Junio C Hamano
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=20110405022235.GA4414@spacedout.fries.net \
--to=david@fries.net \
--cc=alif.wahid@gmail.com \
--cc=git@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=pclouds@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.