timeout

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

timeout

Stephan Herrmann-2
Hi folks,

Gerrit is of very little help these days, timing out more often then not.

Of the last 15 runs, only one succeeded (#2462), which contained this:

----
combined with:
Bug 512740: [newindex] preference to disable the new index does not
disable its rescan job

AND: HARD-DISABLE the new index for now
----

Is that just a coincidence or is the new index really causing our tests
to time out?

(Locally on my machine tests almost always hang during AllJavaModelTests
if the new index is enabled).


Or has s.t. else in the stack degraded in performance?

Some random references to candidate culprits:

HIPP: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14119.html

OOME: https://bugs.eclipse.org/bugs/show_bug.cgi?id=512749

Seeing the compiler in the stack reminds me also of:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=512156


any theories?
Stephan
_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
Reply | Threaded
Open this post in threaded view
|

Re: timeout

Andrey Loskutov
Hi Stephan,

I imagine that max heap default to -Xmx1024m used for SDK is too less
for the old + new index, and that the GC has hard times to free the
memory like in bug 512749 (java.lang.OutOfMemoryError: GC overhead limit
exceeded).

I had already reported this via bug 511693, that for my personal setup
the memory consumption seem to be doubled in 4.7. I don't see OOM errors
but only because I have max heap increased to 3G. In my typical setup,
in the idling Eclipse with ~10 opened editors and lot of Platform
projects in the workspace, JDT uses 520 from 804 MB (used by the JVM),
and more then a half of that (270 MB) is used by the
org.eclipse.jdt.internal.core.nd.db.Chunk objects.

But of course it can be that jdt Hudson has some issues. Have you tried
to restart it (in case Hudson leaks some memory or file descriptors or
both)?

Am 27.02.2017 um 20:44 schrieb Stephan Herrmann:

> Hi folks,
>
> Gerrit is of very little help these days, timing out more often then not.
>
> Of the last 15 runs, only one succeeded (#2462), which contained this:
>
> ----
> combined with:
> Bug 512740: [newindex] preference to disable the new index does not
> disable its rescan job
>
> AND: HARD-DISABLE the new index for now
> ----
>
> Is that just a coincidence or is the new index really causing our tests
> to time out?
>
> (Locally on my machine tests almost always hang during AllJavaModelTests
> if the new index is enabled).
>
>
> Or has s.t. else in the stack degraded in performance?
>
> Some random references to candidate culprits:
>
> HIPP:
> https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14119.html
>
>
> OOME: https://bugs.eclipse.org/bugs/show_bug.cgi?id=512749
>
> Seeing the compiler in the stack reminds me also of:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=512156
>
>
> any theories?
> Stephan

--
Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov
_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
Reply | Threaded
Open this post in threaded view
|

Re: timeout

Stephan Herrmann-2
Where can we see / change the -Xmx used during tests?

*If* this is a memory issue, is it a good idea to ignore the
signal from tests and just accept the higher consumption?

best,
Stephan


On 02/27/2017 09:06 PM, Andrey Loskutov wrote:

> Hi Stephan,
>
> I imagine that max heap default to -Xmx1024m used for SDK is too less for the old + new index, and that the GC has hard times to
> free the memory like in bug 512749 (java.lang.OutOfMemoryError: GC overhead limit exceeded).
>
> I had already reported this via bug 511693, that for my personal setup the memory consumption seem to be doubled in 4.7. I don't see
> OOM errors but only because I have max heap increased to 3G. In my typical setup, in the idling Eclipse with ~10 opened editors and
> lot of Platform projects in the workspace, JDT uses 520 from 804 MB (used by the JVM), and more then a half of that (270 MB) is used
> by the org.eclipse.jdt.internal.core.nd.db.Chunk objects.
>
> But of course it can be that jdt Hudson has some issues. Have you tried to restart it (in case Hudson leaks some memory or file
> descriptors or both)?
>
> Am 27.02.2017 um 20:44 schrieb Stephan Herrmann:
>> Hi folks,
>>
>> Gerrit is of very little help these days, timing out more often then not.
>>
>> Of the last 15 runs, only one succeeded (#2462), which contained this:
>>
>> ----
>> combined with:
>> Bug 512740: [newindex] preference to disable the new index does not
>> disable its rescan job
>>
>> AND: HARD-DISABLE the new index for now
>> ----
>>
>> Is that just a coincidence or is the new index really causing our tests
>> to time out?
>>
>> (Locally on my machine tests almost always hang during AllJavaModelTests
>> if the new index is enabled).
>>
>>
>> Or has s.t. else in the stack degraded in performance?
>>
>> Some random references to candidate culprits:
>>
>> HIPP:
>> https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14119.html
>>
>>
>> OOME: https://bugs.eclipse.org/bugs/show_bug.cgi?id=512749
>>
>> Seeing the compiler in the stack reminds me also of:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=512156
>>
>>
>> any theories?
>> Stephan
>

_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev