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

[David Cheney]

This feels like a bug in mongodb. We store approximately zero data in
mongodb during test runs -- seriously, one machine, a charm at most,
that's it. It mongodb has such amazingly high overheads just start to
store data that sounds like a serious problem that is being ignored.

On Wed, May 18, 2016 at 7:32 PM, 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.
> 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
>>>
>