OOM with 1.120

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

OOM with 1.120

Miroslav Šulc
I do not recall I saw OOM with previous hudson releases but with 1.120
it happened already second time to me. I do not use scm polling as
someone mentioned in another thread. I attached the list of java
processes atm the OOM occurs. I had 4 successful builds since last OOM
and the fifth was OOM again. Tomcat restart (after killing the java
processes) solves the problem for some time.

--
Miroslav Šulc


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

java_processes.txt.bz2 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Miroslav Šulc
Hm, maybe it's caused by one of my tests though I didn't modified that
code lately so it should fail already before. So please forget this
email till I verify it.

Miroslav Šulc napsal(a):
> I do not recall I saw OOM with previous hudson releases but with 1.120
> it happened already second time to me. I do not use scm polling as
> someone mentioned in another thread. I attached the list of java
> processes atm the OOM occurs. I had 4 successful builds since last OOM
> and the fifth was OOM again. Tomcat restart (after killing the java
> processes) solves the problem for some time.
>
> --
> Miroslav Šulc

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Kohsuke Kawaguchi
Administrator
In reply to this post by Miroslav Šulc
You seem to have a quite a lot of processes running there!

For OutOfMemory problem, profiler dump would be very helpful.

Miroslav Šulc wrote:

> I do not recall I saw OOM with previous hudson releases but with 1.120
> it happened already second time to me. I do not use scm polling as
> someone mentioned in another thread. I attached the list of java
> processes atm the OOM occurs. I had 4 successful builds since last OOM
> and the fifth was OOM again. Tomcat restart (after killing the java
> processes) solves the problem for some time.
>
> --
> Miroslav Šulc
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Jesse Glick
Kohsuke Kawaguchi wrote:
> For OutOfMemory problem, profiler dump would be very helpful.

Get in the habit of running with e.g.

   -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp

(At least JDK 6, and I think backported to some newer JDK 5 also.)

You can inspect such dumps using jhat (JDK 6), the NetBeans 6.0
profiler, etc.

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Miroslav Šulc
In reply to this post by Kohsuke Kawaguchi
Yeah, the number of processes was really large. I still do not know how
single ant command could start that many processes, anyway it seems that
the OOM problem was caused by excessive logging of one of tests that
started to fail so this report is invalid.

Thanks.

--
Miroslav Šulc



Kohsuke Kawaguchi napsal(a):

> You seem to have a quite a lot of processes running there!
>
> For OutOfMemory problem, profiler dump would be very helpful.
>
> Miroslav Šulc wrote:
>> I do not recall I saw OOM with previous hudson releases but with
>> 1.120 it happened already second time to me. I do not use scm polling
>> as someone mentioned in another thread. I attached the list of java
>> processes atm the OOM occurs. I had 4 successful builds since last
>> OOM and the fifth was OOM again. Tomcat restart (after killing the
>> java processes) solves the problem for some time.
>>
>> --
>> Miroslav Šulc

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Stephen Connolly-2
Miroslav Šulc wrote
I still do not know how single ant command could start that many processes,
Miroslav Šulc
Are your using a JUnit fork mode of per test?
Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Miroslav Šulc
This is how I run the tests:

        <junit fork="true" forkmode="perBatch" haltonerror="false"
haltonfailure="false">
            <batchtest todir="${build.test.results.dir}">
          ....

and I have only one <batchtest> defined so I suppose it should create
only one fork.

In the list of processes there were even some javadoc processes but
javadoc should be already done atm the tests were run.

--
Miroslav Šulc



Stephen Connolly napsal(a):
> Miroslav Šulc wrote:
>  
>> I still do not know how single ant command could start that many
>> processes,
>> Miroslav Šulc
>>
>>    
> Are your using a JUnit fork mode of per test?
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OOM with 1.120

Stephen Connolly-2
Miroslav Šulc wrote
This is how I run the tests:

        <junit fork="true" forkmode="perBatch" haltonerror="false"
haltonfailure="false">
            <batchtest todir="${build.test.results.dir}">
          ....

and I have only one <batchtest> defined so I suppose it should create
only one fork.

In the list of processes there were even some javadoc processes but
javadoc should be already done atm the tests were run.
OK, well it was just a guess as to how you could have lots of processes from one simple ant task!