Re: Performance issue: initial git clone causes massive repack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2009.04.05 23:24:27 -0400, Nicolas Pitre wrote:
> On Sun, 5 Apr 2009, Sverre Rabbelier wrote:
> 
> > Heya,
> > 
> > On Sun, Apr 5, 2009 at 23:28,  <david@xxxxxxx> wrote:
> > > Guys, back off a little on telling the gentoo people to change.
> > 
> > I agree here, we should either say "look, we don't really support big
> > repositories because [explanation here], unless you [workarounds
> > here]" OR we should work to improve the support we do have. Of course,
> > the latter option does not magically create developer time to work on
> > that, but if we do go that way we should at least tell people that we
> > are aware of the problems and that it's on the global TODO list (not
> > necessarily on anyone's personal TODO list though).
> 
> For the record... I at least am aware of the problem and it is indeed on 
> my personal git todo list.  Not that I have a clear solution yet (I've 
> been pondering on some git packing issues for almost 4 years now).
> 
> Still, in this particular case, the problem appears to be unclear to me, 
> like "this shouldn't be so bad".

It's not primarily pack-objects, I think. It's the rev-list that's run
by upload-pack.  Running "git rev-list --objects --all" on that repo
eats about 2G RSS, easily killing the system's cache on a small box,
leading to swapping and a painful time reading the packfile contents
afterwards to send them to the client.

Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]