Re: Flurries of 'git reflog expire'

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 4, 2017, 09:43 UTC
Message-ID: <87podgbkqi.fsf@gmail.com>
In-Reply-To: <20170704075758.GA22249@inner.h.apk.li>

On Tue, Jul 04 2017, Andreas Krey jotted:

Show 6 quoted lines

> 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'

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)?

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.