Re: Something is broken in repack

From: Nicolas Pitre <nico@cam.org>
Date: Dec 11, 2007, 15:00 UTC
Message-ID: <alpine.LFD.0.99999.0712110951070.555@xanadu.home>
In-Reply-To: <alpine.LFD.0.99999.0712110832251.555@xanadu.home>

On Tue, 11 Dec 2007, Nicolas Pitre wrote:

Show 9 quoted lines

> And yet, this is still missing the actual issue.  The issue being that 
> the 2.1GB pack as a _source_ doesn't cause as much memory to be 
> allocated even if the _result_ pack ends up being the same.
> 
> I was able to repack the 2.1GB pack on my machine which has 1GB of ram. 
> Now that it has been repacked, I can't repack it anymore, even when 
> single threaded, as it start crowling into swap fairly quickly.  It is 
> really non intuitive and actually senseless that Git would require twice 
> as much RAM to deal with a pack that is 7 times smaller.

OK, here's something else for you to try:

	core.deltabasecachelimit=0
	pack.threads=2
	pack.deltacachesize=1

With that I'm able to repack the small gcc pack on my machine with 1GB of ram using:

	git repack -a -f -d --window=250 --depth=250

and top reports a ~700m virt and ~500m res without hitting swap at all. It is only at 25% so far, but I was unable to get that far before.

Would be curious to know what you get with 4 threads on your machine.

Nicolas