Re: Flurries of 'git reflog expire'
- Date: Wed, 5 Jul 2017 04:20:27 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: Flurries of 'git reflog expire'
On Tue, Jul 04, 2017 at 09:57:58AM +0200, Andreas Krey wrote:
> 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
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?