You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Stefan Egli <st...@apache.org> on 2016/02/09 19:17:47 UTC
travis needs more memory
Hi,
Looks like we need to give our travis run [0] more memory. OAK-3986 was
likely partly slowing down due to memory becoming low. Now it looks like
ConcurrentAddIT is failing [1] for the same reason too (can reproduce this
locally: default memory settings result in OOME). I'm guessing adding this
to the .travis.yml would do the trick?
env:
global:
- JAVA_OPTS="-Xmx1G"
Cheers,
Stefan
--
[0] - https://travis-ci.org/apache/jackrabbit-oak/builds
[1] -
Running org.apache.jackrabbit.oak.jcr.ConcurrentAddIT
No output has been received in the last 10 minutes, this potentially
indicates a stalled build or something wrong with the build itself.
The build has been terminated
Re: travis needs more memory
Posted by Michael Dürig <md...@apache.org>.
Hi,
FWIW, our Jenkins instance also failed with OOM:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/737/
Michael
On 10.2.16 9:04 , Marcel Reutegger wrote:
> Hi,
>
> this may solve the immediate issue with the test
> failure, but it probably also hides an memory problem
> with our tests. in the past I tried to first identify
> and fix memory leaks and only then increase the heap
> if really necessary. do you know what is holding on
> to the memory?
>
> Regards
> Marcel
>
> On 09/02/16 19:17, "Stefan Egli" wrote:
>
>> Hi,
>>
>> Looks like we need to give our travis run [0] more memory. OAK-3986 was
>> likely partly slowing down due to memory becoming low. Now it looks like
>> ConcurrentAddIT is failing [1] for the same reason too (can reproduce this
>> locally: default memory settings result in OOME). I'm guessing adding this
>> to the .travis.yml would do the trick?
>>
>> env:
>>
>> global:
>>
>> - JAVA_OPTS="-Xmx1G"
>>
>>
>> Cheers,
>> Stefan
>> --
>> [0] - https://travis-ci.org/apache/jackrabbit-oak/builds
>> [1] -
>> Running org.apache.jackrabbit.oak.jcr.ConcurrentAddIT
>> No output has been received in the last 10 minutes, this potentially
>> indicates a stalled build or something wrong with the build itself.
>>
>> The build has been terminated
>>
>>
>
Re: travis needs more memory
Posted by Julian Reschke <ju...@gmx.de>.
On 2016-02-10 17:02, Stefan Egli wrote:
> On 10/02/16 14:59, "Davide Giannella" <da...@apache.org> wrote:
>
>> On 10/02/2016 10:22, Stefan Egli wrote:
>>> Re NonLocalObservationIT, that one creates like 160'000 nodes in-memory
>>> and that seems not to fit the default VM settings.
>>
>> Shall we move this to a SegmentFixture?
>
> Or DocumentFixture because the test needs to simulate a cluster. It looks
> like OAK-3803 removed 'cluster support' from the NodeStoreFixtures - they
> all return null now in createNodeStore(clusterNodeId) - which I originally
> worked around by creating a new in-memory fixture. But yes, actually the
> test should run against mongo.
>
> Was there a particular reason for removing cluster support in OAK-3803?
I recall that at some point, it wasn't used and also didn't work
properly, so that would be a good reason to remove the feature during
refactoring...
Re: travis needs more memory
Posted by Stefan Egli <st...@apache.org>.
On 10/02/16 14:59, "Davide Giannella" <da...@apache.org> wrote:
>On 10/02/2016 10:22, Stefan Egli wrote:
>> Re NonLocalObservationIT, that one creates like 160'000 nodes in-memory
>> and that seems not to fit the default VM settings.
>
>Shall we move this to a SegmentFixture?
Or DocumentFixture because the test needs to simulate a cluster. It looks
like OAK-3803 removed 'cluster support' from the NodeStoreFixtures - they
all return null now in createNodeStore(clusterNodeId) - which I originally
worked around by creating a new in-memory fixture. But yes, actually the
test should run against mongo.
Was there a particular reason for removing cluster support in OAK-3803?
Cheers,
Stefan
Re: travis needs more memory
Posted by Davide Giannella <da...@apache.org>.
On 10/02/2016 10:22, Stefan Egli wrote:
> Re NonLocalObservationIT, that one creates like 160'000 nodes in-memory
> and that seems not to fit the default VM settings.
Shall we move this to a SegmentFixture?
Davide
Re: travis needs more memory
Posted by Stefan Egli <st...@apache.org>.
Re NonLocalObservationIT, that one creates like 160'000 nodes in-memory
and that seems not to fit the default VM settings.
Re the other test (ConcurrentAddIT) I don't know.
Cheers,
Stefan
On 10/02/16 09:04, "Marcel Reutegger" <mr...@adobe.com> wrote:
>Hi,
>
>this may solve the immediate issue with the test
>failure, but it probably also hides an memory problem
>with our tests. in the past I tried to first identify
>and fix memory leaks and only then increase the heap
>if really necessary. do you know what is holding on
>to the memory?
>
>Regards
> Marcel
>
>On 09/02/16 19:17, "Stefan Egli" wrote:
>
>>Hi,
>>
>>Looks like we need to give our travis run [0] more memory. OAK-3986 was
>>likely partly slowing down due to memory becoming low. Now it looks like
>>ConcurrentAddIT is failing [1] for the same reason too (can reproduce
>>this
>>locally: default memory settings result in OOME). I'm guessing adding
>>this
>>to the .travis.yml would do the trick?
>>
>>env:
>>
>>global:
>>
>>- JAVA_OPTS="-Xmx1G"
>>
>>
>>Cheers,
>>Stefan
>>--
>>[0] - https://travis-ci.org/apache/jackrabbit-oak/builds
>>[1] -
>>Running org.apache.jackrabbit.oak.jcr.ConcurrentAddIT
>>No output has been received in the last 10 minutes, this potentially
>>indicates a stalled build or something wrong with the build itself.
>>
>>The build has been terminated
>>
>>
>
Re: travis needs more memory
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
this may solve the immediate issue with the test
failure, but it probably also hides an memory problem
with our tests. in the past I tried to first identify
and fix memory leaks and only then increase the heap
if really necessary. do you know what is holding on
to the memory?
Regards
Marcel
On 09/02/16 19:17, "Stefan Egli" wrote:
>Hi,
>
>Looks like we need to give our travis run [0] more memory. OAK-3986 was
>likely partly slowing down due to memory becoming low. Now it looks like
>ConcurrentAddIT is failing [1] for the same reason too (can reproduce this
>locally: default memory settings result in OOME). I'm guessing adding this
>to the .travis.yml would do the trick?
>
>env:
>
>global:
>
>- JAVA_OPTS="-Xmx1G"
>
>
>Cheers,
>Stefan
>--
>[0] - https://travis-ci.org/apache/jackrabbit-oak/builds
>[1] -
>Running org.apache.jackrabbit.oak.jcr.ConcurrentAddIT
>No output has been received in the last 10 minutes, this potentially
>indicates a stalled build or something wrong with the build itself.
>
>The build has been terminated
>
>