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:joshcanfi...@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" <j...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
