Re: Flurries of 'git reflog expire'
- Date: Tue, 04 Jul 2017 11:43:33 +0200
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: Flurries of 'git reflog expire'
On Tue, Jul 04 2017, Andreas Krey jotted:
> Hi everyone,
> how is 'git reflog expire' triggered? We're occasionally seeing a lot
> of the running in parallel on a single of our repos (atlassian bitbucket),
> and this usually means that the machine is not very responsive for
> twenty minutes, the repo being as big as it is.
Assuming Linux, what does 'ps auxf' look like when this happens? Is the
parent a 'git gc --auto'?
> The server is still on git 2.6.2 (and bitbucket 4.14.5).
You might want to upgrade, we've had a bunch of changes since then,
maybe some of this fixes it:
git log --reverse -p -L'/^static.*lock_repo_for/,/^}/:builtin/gc.c'
> 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)?
You can set gc.auto=0 in the repo to disable auto-gc, and play with
e.g. the reflog expire values, see the git-gc manpage.
But then you need to run your own gc, which is not a bad idea anyway
with a dedicated git server.
But it would be good to get to the bottom of this, we shouldn't be
running these concurrently.