You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jim O'Callaghan <ji...@peritussolutions.com> on 2010/10/29 17:35:23 UTC
Memory creep
I'm testing a Tapestry app running under Jetty on Windows using multiple
Selenium IDE sessions and have noticed a creep of about 130MB RAM per hour
on my java exe when running through a test loop that logs in to the app,
runs through some expected user behaviour (some search screens, detail
screens, minor amounts of data entry / persistence) and then logs out.
Each test loop iteration takes about 40 seconds. Upon log out, the http
session is destroyed and I am running six concurrent sessions at the
moment. The test script does not vary the entities retrieved from the
database so beyond the initial entity caching I would not expect the memory
usage to keep increasing, i.e. it should bottom out at some stage.
I've found this with T.5.2.0 and also T.5.2.1, and the current JVM I'm using
is from jdk1.6.0_21_x64 on Jetty 6.1.18. I'm working my way through
different JVMs at the moment to see if there is much of a difference. Given
that the entities loaded are the same during the test loops, the HTTP
session is destroyed during each loop cycle, and the memory footprint
appears to stay at the same level after the tests are stopped, could anyone
give any pointers to Tapestry areas to look at to try to identify the cause
of the memory creep? Or perhaps this is a JVM / Jetty issue? Having
trawled through the list before on related GC issues, I'm using the
following JVM settings:
-server
-Xms1408m
-Xmx1536m
-XX:MaxPermSize=256m
-XX:NewSize=384m
-XX:SurvivorRatio=2
With such a noticeable creep (initially approx 650MB with 6 sessions rising
to 780MB after 1 hour) reproducible on a dev machine I'm concerned that this
app won't make it out of dev unless I can get to the bottom of the problem.
Regards,
Jim.
Re: Memory creep
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 29 Oct 2010 15:30:23 -0200, Josh Canfield <jo...@gmail.com>
wrote:
>> but your suggestion of forcing garbage collection - can you give me some
>> detail on how to go about that?
>
> http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
VisualVM (https://visualvm.dev.java.net/) has a very nice GUI for it.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Memory creep
Posted by Josh Canfield <jo...@gmail.com>.
> I think I'm would be getting OOM if I left the tests running for long enough
Until you actually hit a barrier that causes a garbage collection
you'll never know how much actual memory your application is using and
how much garbage is sitting around.
I just randomly grabbed this article which appears to have good
information, but I only scanned it so YMMV.
http://www.petefreitag.com/articles/gctuning/
> but your suggestion of forcing garbage collection - can you give me some
> detail on how to go about that?
http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html
You can use jconsole to get a decent amount of info about the running vm.
> I thought the JVM just took the GC related
> settings at startup and managed things on its own from then on in?
Yep, it does. There are lots of choices depending on your needs/wants.
You aren't actually seeing a problem, you suspect you are seeing a
problem. Everything could be working fine :) You could drop your max
memory down to 700m and re-run your tests and see if you start getting
OOM, or if the GC cleans things up then you've got nothing to worry
about.
Josh
On Fri, Oct 29, 2010 at 9:39 AM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Thanks for the suggestions Josh - I'm just starting to work through the app
> with the Eclipse Memory Profiler to see if I can spot what's going on.
>
> I think I'm would be getting OOM if I left the tests running for long enough
> but your suggestion of forcing garbage collection - can you give me some
> detail on how to go about that? I thought the JVM just took the GC related
> settings at startup and managed things on its own from then on in?
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Josh Canfield [mailto:joshcanfield@gmail.com]
> Sent: 29 October 2010 17:00
> To: Tapestry users
> Subject: Re: Memory creep
>
> Can you run it with a profiler? Something like Yourkit will tell you what is
> being used.
>
> Also, have you forced garbage collection? It doesn't sound like you're
> getting OOM so maybe you've got garbage laying around?
> On 29 Oct 2010 08:36, "Jim O'Callaghan" <ji...@peritussolutions.com>
> wrote:
>> I'm testing a Tapestry app running under Jetty on Windows using multiple
>> Selenium IDE sessions and have noticed a creep of about 130MB RAM per hour
>> on my java exe when running through a test loop that logs in to the app,
>> runs through some expected user behaviour (some search screens, detail
>> screens, minor amounts of data entry / persistence) and then logs out.
>> Each test loop iteration takes about 40 seconds. Upon log out, the http
>> session is destroyed and I am running six concurrent sessions at the
>> moment. The test script does not vary the entities retrieved from the
>> database so beyond the initial entity caching I would not expect the
> memory
>> usage to keep increasing, i.e. it should bottom out at some stage.
>>
>> I've found this with T.5.2.0 and also T.5.2.1, and the current JVM I'm
> using
>> is from jdk1.6.0_21_x64 on Jetty 6.1.18. I'm working my way through
>> different JVMs at the moment to see if there is much of a difference.
> Given
>> that the entities loaded are the same during the test loops, the HTTP
>> session is destroyed during each loop cycle, and the memory footprint
>> appears to stay at the same level after the tests are stopped, could
> anyone
>> give any pointers to Tapestry areas to look at to try to identify the
> cause
>> of the memory creep? Or perhaps this is a JVM / Jetty issue? Having
>> trawled through the list before on related GC issues, I'm using the
>> following JVM settings:
>>
>> -server
>>
>> -Xms1408m
>>
>> -Xmx1536m
>>
>> -XX:MaxPermSize=256m
>>
>> -XX:NewSize=384m
>>
>> -XX:SurvivorRatio=2
>>
>> With such a noticeable creep (initially approx 650MB with 6 sessions
> rising
>> to 780MB after 1 hour) reproducible on a dev machine I'm concerned that
> this
>> app won't make it out of dev unless I can get to the bottom of the
> problem.
>>
>>
>>
>> Regards,
>>
>> Jim.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Memory creep
Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks for the suggestions Josh - I'm just starting to work through the app
with the Eclipse Memory Profiler to see if I can spot what's going on.
I think I'm would be getting OOM if I left the tests running for long enough
but your suggestion of forcing garbage collection - can you give me some
detail on how to go about that? I thought the JVM just took the GC related
settings at startup and managed things on its own from then on in?
Regards,
Jim.
-----Original Message-----
From: Josh Canfield [mailto:joshcanfield@gmail.com]
Sent: 29 October 2010 17:00
To: Tapestry users
Subject: Re: Memory creep
Can you run it with a profiler? Something like Yourkit will tell you what is
being used.
Also, have you forced garbage collection? It doesn't sound like you're
getting OOM so maybe you've got garbage laying around?
On 29 Oct 2010 08:36, "Jim O'Callaghan" <ji...@peritussolutions.com>
wrote:
> I'm testing a Tapestry app running under Jetty on Windows using multiple
> Selenium IDE sessions and have noticed a creep of about 130MB RAM per hour
> on my java exe when running through a test loop that logs in to the app,
> runs through some expected user behaviour (some search screens, detail
> screens, minor amounts of data entry / persistence) and then logs out.
> Each test loop iteration takes about 40 seconds. Upon log out, the http
> session is destroyed and I am running six concurrent sessions at the
> moment. The test script does not vary the entities retrieved from the
> database so beyond the initial entity caching I would not expect the
memory
> usage to keep increasing, i.e. it should bottom out at some stage.
>
> I've found this with T.5.2.0 and also T.5.2.1, and the current JVM I'm
using
> is from jdk1.6.0_21_x64 on Jetty 6.1.18. I'm working my way through
> different JVMs at the moment to see if there is much of a difference.
Given
> that the entities loaded are the same during the test loops, the HTTP
> session is destroyed during each loop cycle, and the memory footprint
> appears to stay at the same level after the tests are stopped, could
anyone
> give any pointers to Tapestry areas to look at to try to identify the
cause
> of the memory creep? Or perhaps this is a JVM / Jetty issue? Having
> trawled through the list before on related GC issues, I'm using the
> following JVM settings:
>
> -server
>
> -Xms1408m
>
> -Xmx1536m
>
> -XX:MaxPermSize=256m
>
> -XX:NewSize=384m
>
> -XX:SurvivorRatio=2
>
> With such a noticeable creep (initially approx 650MB with 6 sessions
rising
> to 780MB after 1 hour) reproducible on a dev machine I'm concerned that
this
> app won't make it out of dev unless I can get to the bottom of the
problem.
>
>
>
> Regards,
>
> Jim.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Memory creep
Posted by Josh Canfield <jo...@gmail.com>.
Can you run it with a profiler? Something like Yourkit will tell you what is
being used.
Also, have you forced garbage collection? It doesn't sound like you're
getting OOM so maybe you've got garbage laying around?
On 29 Oct 2010 08:36, "Jim O'Callaghan" <ji...@peritussolutions.com>
wrote:
> I'm testing a Tapestry app running under Jetty on Windows using multiple
> Selenium IDE sessions and have noticed a creep of about 130MB RAM per hour
> on my java exe when running through a test loop that logs in to the app,
> runs through some expected user behaviour (some search screens, detail
> screens, minor amounts of data entry / persistence) and then logs out.
> Each test loop iteration takes about 40 seconds. Upon log out, the http
> session is destroyed and I am running six concurrent sessions at the
> moment. The test script does not vary the entities retrieved from the
> database so beyond the initial entity caching I would not expect the
memory
> usage to keep increasing, i.e. it should bottom out at some stage.
>
> I've found this with T.5.2.0 and also T.5.2.1, and the current JVM I'm
using
> is from jdk1.6.0_21_x64 on Jetty 6.1.18. I'm working my way through
> different JVMs at the moment to see if there is much of a difference.
Given
> that the entities loaded are the same during the test loops, the HTTP
> session is destroyed during each loop cycle, and the memory footprint
> appears to stay at the same level after the tests are stopped, could
anyone
> give any pointers to Tapestry areas to look at to try to identify the
cause
> of the memory creep? Or perhaps this is a JVM / Jetty issue? Having
> trawled through the list before on related GC issues, I'm using the
> following JVM settings:
>
> -server
>
> -Xms1408m
>
> -Xmx1536m
>
> -XX:MaxPermSize=256m
>
> -XX:NewSize=384m
>
> -XX:SurvivorRatio=2
>
> With such a noticeable creep (initially approx 650MB with 6 sessions
rising
> to 780MB after 1 hour) reproducible on a dev machine I'm concerned that
this
> app won't make it out of dev unless I can get to the bottom of the
problem.
>
>
>
> Regards,
>
> Jim.
>