1294706 - "Mochitest other" chunk on win7 debug slow and often last to complete

Status: NEW

(Testing :: Mochitest, defect)

Description

[William Lachance (:wlach)]

Similar to mochitest dt9 (bug 1294489), based on Infraherder it looks like Mochitest other on win7 debug often takes significantly longer than its mochitest breathen, frequently becoming the long poll in a sequence of jobs:

e.g. in this try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=8f6eac7f74fb7775617e3acd089aec43de3e24ff&selectedJob=25873461

M-1: 37 minute(s)
M-2: 40
M-3: 52
M-4: 37
bc-1: 28
bc-2: 31
bc3: 34
bc4: 35
bc5: 30
bc6: 29
bc7: 24
cl: 29
gl: 50
---> o: 82 <---

Renormalizing the chunk size might be in order?

This chunk also seems to be a problem on linux: https://treeherder.mozilla.org/index.html#/jobs?repo=try&revision=a82435791b8198de368cd322da798e138408891e&selectedJob=25876934

Comment 1

[(not currently active) Ted Mielczarek]

mochitest-other runs several Mochitest variants together. Historically we did that to amortize the setup time over a few short jobs, but maybe it's time to split them out into their own jobs? It looks like all that's left in there is mochitest-chrome and mochitest-a11y, so splitting that into two jobs does not seem unreasonable.

Comment 2

[William Lachance (:wlach)]

Another problem with these long running jobs is that our "auto retrigger failing jobs on try" behaviour will waste 2x the # of cycles. You can see that in the example I linked to above.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

prior art in bug 1211889, we didn't have enough builders in buildbot to do this in the past.  It might be worth trying again, I think linux64 was the main issue.