Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

[Christian Muirhead]

Michael, thanks for all the clear info in the bugs by the way!

I also got good results from running the tests under tmpfs - the 3.2 run
was almost acceptably fast. But obviously it's not practical to require
every machine running the tests to have a tmpfs mounted (or somehow mount
one in the test run).

On Wed, May 18, 2016 at 10:36 AM Michael Hudson-Doyle <
michael.hudson at canonical.com> wrote:

> On 18 May 2016 at 21:32, Christian Muirhead
> <christian.muirhead at canonical.com> wrote:
> > WiredTiger is *much* slower at creating and dropping indexes and
> > collections. I haven't worked out why that is, other than doing some
> > stracing and seeing that a lot of time is spent in fdatasync - I haven't
> dug
> > into the mongo source code.
>
> Yeah, this is what I concluded too. I tried running mongo under
> eatmydata but it didn't work for reasons I didn't get around to
> understanding. I even built a mongo with the fdatasync call commented
> out but then I moved onto other things...
>
> Cheers,
> mwh
>
> > There's a bit more detail in these bugs:
> > https://bugs.launchpad.net/juju-core/+bug/1573294
> > https://jira.mongodb.org/browse/SERVER-21198
> >
> > I've changed the tests so that instead of dropping and recreating
> databases
> > in teardown and setup we clear out all of the collections (except the
> > transaction collections) between tests. Obviously that's worse from the
> > perspective of test isolation, but it seems to work well - better than I
> was
> > expecting, to be honest.
> >
> > Cheers,
> > Christian
> >
> > On Wed, May 18, 2016 at 9:58 AM roger peppe <roger.peppe at canonical.com>
> > wrote:
> >>
> >> Out of interest, what's causing the 3.2 slowdown and what's the hack to
> >> speed it up again?
> >>
> >> On 18 May 2016 09:51, "Christian Muirhead"
> >> <christian.muirhead at canonical.com> wrote:
> >>>
> >>>
> >>>
> >>> On Wed, May 18, 2016 at 2:04 AM David Cheney <
> david.cheney at canonical.com>
> >>> wrote:
> >>>>
> >>>> 100x more webscale
> >>>
> >>> Ha!
> >>>
> >>> I'm *just about* finished the hack to make the state tests on 3.2 run
> in
> >>> about the same time as on 2.4. On my machine the state tests take
> 6m24s on
> >>> 3.2 and the old version took 4m56s. Which is still worse,
> unfortunately, but
> >>> at least it isn't 100x worse. So if there are stability benefits to
> running
> >>> the tests on 3.2 it's still a win, I guess?
> >>>
> >>>
> >>>>
> >>>>
> >>>> On Wed, May 18, 2016 at 11:02 AM, Horacio Duran
> >>>> <horacio.duran at canonical.com> wrote:
> >>>> > For now we are trying to go around mongo issues that make the tests
> >>>> > 100x
> >>>> > slower (yes one hundred) once this is fixed we should start using
> >>>> > mongo 3.2
> >>>> > exclusively since 2.4 iirc is EOL or near. The issue lies in the new
> >>>> > storage
> >>>> > engine, which we could skip if mmapv1 ( the old one) wasn't also
> >>>> > nearing EOL
> >>>> > I am currently on the phone but if You want more details I can dig
> up
> >>>> > the
> >>>> > bug with details of what I am talking about.
> >>>> >
> >>>> >
> >>>> > On Tuesday, 17 May 2016, David Cheney <david.cheney at canonical.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> What's the plan for mongo 3.2 ? Will we be required to support 2.x
> >>>> >> versions for the foreseeable future, or is there a possibility to
> >>>> >> make
> >>>> >> it a build or run time failure if mongo < 3.2 is installed on the
> >>>> >> host
> >>>> >> ?
> >>>> >>
> >>>> >> On Wed, May 18, 2016 at 9:01 AM, Martin Packman
> >>>> >> <martin.packman at canonical.com> wrote:
> >>>> >> > On 17/05/2016, Curtis Hovey-Canonical <curtis at canonical.com>
> wrote:
> >>>> >> >>
> >>>> >> >> The juju-mongo2.6 package will be be preferred by juju 1.2.5 in
> >>>> >> >> xenial
> >>>> >> >> and without other changes, 2.4 will be used by all other 1.25
> >>>> >> >> series.
> >>>> >> >
> >>>> >> > This isn't yet true, there's a bug open for it:
> >>>> >> >
> >>>> >> > "Use juju-mongodb2.6 for 1.25 on xenial"
> >>>> >> > <
> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1570650>
> >>>> >> >
> >>>> >> > I had made the packaging change, but without juju code changes as
> >>>> >> > well
> >>>> >> > it just went and installed the old (2.4) juju-mongodb anyway when
> >>>> >> > setting up a state server.
> >>>> >> >
> >>>> >> > Martin
> >>>> >> >
> >>>> >> > --
> >>>> >> > Juju-dev mailing list
> >>>> >> > Juju-dev at lists.ubuntu.com
> >>>> >> > Modify settings or unsubscribe at:
> >>>> >> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>> >>
> >>>> >> --
> >>>> >> Juju-dev mailing list
> >>>> >> Juju-dev at lists.ubuntu.com
> >>>> >> Modify settings or unsubscribe at:
> >>>> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>>
> >>>> --
> >>>> Juju-dev mailing list
> >>>> Juju-dev at lists.ubuntu.com
> >>>> Modify settings or unsubscribe at:
> >>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>
> >>>
> >>> --
> >>> Juju-dev mailing list
> >>> Juju-dev at lists.ubuntu.com
> >>> Modify settings or unsubscribe at:
> >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>>
> >
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160518/c6954cf3/attachment.html>