All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Poole <mdpoole@troilus.org>
To: Miles Bader <miles@gnu.org>, Michael Witten <mfwitten@gmail.com>
Cc: Frans Pop <elendil@planet.nl>, git@vger.kernel.org
Subject: Re: 'git gc --aggressive' effectively unusable
Date: Sun, 04 Apr 2010 10:50:47 -0400	[thread overview]
Message-ID: <87zl1js248.fsf@troilus.org> (raw)
In-Reply-To: <87oci0m5v4.fsf@catnip.gol.com> (Miles Bader's message of "Sun, 04 Apr 2010 09:14:07 +0900")

Miles Bader writes:

> Frans Pop <elendil@planet.nl> writes:
>>> > I haven't had the patience to let it finish
>>>
>>> There's your problem.
>>
>> Yes, I had seen that. But there's a difference between taking much more 
>> time and slowing down to such an extend that it never finishes.
>>
>> I've tried it today on my linux-2.6 repo as well and the same thing 
>> happened. At first the progress is not fast but reasonable. When it gets 
>> to about 45% percent it starts slowing down a lot: from ~1500 objects per 
>> update of the counters to ~300 objects per update. And who knows what the 
>> progress is going to be when it reaches 70% or 90%: 10 per update?
>
> Are you sure it doesn't subsequently speed up again?

I have seen asymptotic slowdown as "git gc --aggressive" progresses on
certain repositories.  It is particularly bad with
git://git.infradead.org/gcc.git (on an x86-64 system with 4 GB RAM).
git seemed to be thrashing swap badly as time went on.  I don't know
that git gc --aggressive would *never* finish on my gcc-git repository.
I just know that it got to about 80% done in less than an hour, to 90%
after twelve hours, and about 94% after another twelve hours.  (The same
operation on linux-2.6.git takes about 40 minutes with all the default
settings.)

I may have been dreaming, but I thought with some 1.6.x version of git,
reducing core.packedGitLimit and pack.windowLimit (now windowMemory?)
mostly made the thrashing go away.  When I try again with v1.7.0.2,
though, it doesn't seem to help very much -- there is still a lot of
swapping, and the git process got to about 7 GB virtual size before I
killed it after about 10 hours of operation.

Michael Poole

  reply	other threads:[~2010-04-04 14:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-02 22:05 'git gc --aggressive' effectively unusable Frans Pop
2010-04-02 22:12 ` Frans Pop
2010-04-03 21:16 ` Frans Pop
2010-04-03 21:33 ` Michael Witten
2010-04-03 21:42   ` Michael Witten
2010-04-03 23:23   ` Frans Pop
2010-04-03 23:42     ` Michael Witten
2010-04-04  0:14     ` Miles Bader
2010-04-04 14:50       ` Michael Poole [this message]
2010-04-04 20:38         ` Jeff King
2010-04-04 21:49           ` Jeff King
2010-04-05 21:07             ` Nicolas Pitre
2010-04-04  4:27     ` Mike Galbraith

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=87zl1js248.fsf@troilus.org \
    --to=mdpoole@troilus.org \
    --cc=elendil@planet.nl \
    --cc=git@vger.kernel.org \
    --cc=mfwitten@gmail.com \
    --cc=miles@gnu.org \
    /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.