Re: Flurries of 'git reflog expire'

From: Jeff King <peff@peff.net>
Date: Jul 5, 2017, 08:20 UTC
Message-ID: <20170705082027.ujddejajjlvto7bp@sigill.intra.peff.net>
In-Reply-To: <20170704075758.GA22249@inner.h.apk.li>

On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:

Show 8 quoted lines

> Questions:
> 
> What can be done about this? Cronjob 'git reflog expire' at midnight,
> so the heuristic don't trigger during the day? (The relnotes don't
> mention anything after 2.4.0, so I suppose a git upgrade won't help.)
> 
> What is the actual cause? Bad heuristics in git itself, or does
> bitbucket run them too often (improbable)?

If it's using --expire-unreachable (which a default "git gc" does), that means the we have to traverse the entire history to see what is reachable and what is not. Added on to a normal git-gc, that's usually not a big deal (it has to do that traversal and much more for the repack). But if bitbucket is triggering it for other operations, that could be related (I don't think anything but gc should ever run it otherwise).

I seem to recall that using --stale-fix is also extremely expensive, too. What do the command line arguments for the slow commands look like? And what does the process tree look like?

-Peff