554656 - Automatically prune try repo

Status: RESOLVED DUPLICATE of bug 1055298

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Chris AtLee [:catlee]]

Our try repo accumulates a lot of heads over time, which slows down hg eventually.  It would be nice to be able to prune older heads.

Comment 1

[Justin Wood (:Callek)]

Since we don't have any presumption of try being a stable-pullable repo, would it be possible to periodically just drop its current state on the floor, and re-push a copy from our then-current m-c to the same location.

Instead of trying to do some unsupported function of hg?

[Note I'm not sure if any of our infra needs the head information AFTER the fact]

Comment 2

[(not currently active) Ted Mielczarek]

That's what we currently do. We're looking for a solution that we can enact without having to enforce a downtime while we nuke the entire repo.

Comment 3

[Chris AtLee [:catlee]]

(In reply to comment #1)
> Since we don't have any presumption of try being a stable-pullable repo, would
> it be possible to periodically just drop its current state on the floor, and
> re-push a copy from our then-current m-c to the same location.
> 
> Instead of trying to do some unsupported function of hg?
> 
> [Note I'm not sure if any of our infra needs the head information AFTER the
> fact]

Yeah, there's the risk of breaking builds if we drop the entire repo.  There's always *some* delay between a change being pushed to try, and the hg checkout being started.  This delay can be several minutes depending on if there's a free build slave available or not.  If we reset the entire repo in this period, then the subsequent hg clone will fail.

Comment 5

[Dirkjan Ochtman (:djc)]

Adding some people from the other bugs. See https://bugzilla.mozilla.org/show_bug.cgi?id=557325 (especially comment 6) for solutions here. Bug 563340 may also have useful information.

Comment 6

[Chris AtLee [:catlee]]

As per bug 563340, if we can determine why try is so slow, and fix the underlying issue, then we wouldn't have to prune the repo automatically.  Pruning is just a workaround.

Comment 7

[(no longer active)]

Is the issue here only the number of heads?  If yes, can we backout every branch that people push and merge it against the base mozilla-central changeset, to get rid of the added head?

Comment 8

[[e-mail] (:bhearsum)]

(In reply to comment #7)
> Is the issue here only the number of heads?  If yes, can we backout every
> branch that people push and merge it against the base mozilla-central
> changeset, to get rid of the added head?

Yeah, number of heads is the issue AFAIK. If we did this directly on an hg host we'd avoid getting these merges in pushlog, too, so we wouldn't get builds from them -- which is ideal.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

This is bad again:

time wget http://hg.mozilla.org/try/rev/e61a1699f49c
--14:21:12--  http://hg.mozilla.org/try/rev/e61a1699f49c
           => `e61a1699f49c'
Resolving hg.mozilla.org... 63.245.208.189
Connecting to hg.mozilla.org|63.245.208.189|:80... connected.
HTTP request sent, awaiting response... 200 Script output follows
Length: unspecified [text/html]

    [   <=>                               ] 45,685        47.67K/s             

14:21:29 (47.52 KB/s) - `e61a1699f49c' saved [45685]


real	0m17.285s
user	0m0.002s
sys	0m0.009s

Comment 10

[Nick Thomas [:nthomas] (UTC+12)]

There's two issues here I think:
1) accessing the try repo itself (eq comment #9) becomes slow; impacts people who're inspecting changesets and possibly build slaves pulling to build. Trimming heads may help
2) querying pushlog becomes slow, which impacts tbpl and buildbot

Ted, any thoughts on whether 2) is fixed by trimming heads ?

Comment 11

[(not currently active) Ted Mielczarek]

The pushlog queries that buildbot do should not touch the repo at all. (The feed simply hits the database.)

TBPL hits the HTML page, which does have to query the repo to get the changeset author and commit message.

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

I'm not actively working on this, putting it back in the pool.