Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)

[Kalle Korhonen <ka...@gmail.com>]

I applaud the efforts, but I think you really really have to upgrade
to 5.1.0.5 before you can get this on anybody's radar. There's a good
possibility the same wouldn't happen in it. If you are running with
-server (think it may be automatically chosen if you haven't specified
with that heap max) and the application is sufficiently busy, the gc
wouldn't kick in until heap space is exhausted. Have you checked that
you are closing db connections/returning them to to the pool properly?
In any case obviously this is not right, you shouldn't need to accept
memory usage of 2GB with that load. I've been able to run small
db-backed Tapestry apps with a memory budget of less than 200MB.

Kalle


On Fri, Sep 11, 2009 at 8:47 AM, Dave Greggory <da...@yahoo.com> wrote:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit  -Xms2048m -Xmx2048m  -XX:PermSize=128m  -XX:MaxPermSize=128m.
>
> Configured as:
>    tapestry.page-pool.active-window = 5 m
>    tapestry.page-pool.hard-limit = 10
>
> Ran a JMeter Load Test with
>    10 concurrent users
>    Ramp-up time of 60 seconds
>    1 second between requests for a particular user
>    Repeated 20 times
>
> The user will visit a signup page, submit a form, then get redirected to a billing page, submit that with CC info and be shown a thank you receipt page and will log out. During the test, memory usage went from around 400MB to 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB at most. Re-ran the above test with 20 users instead with the same config (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it finally threw an OOM with a memory dump.
>
> JConsole Memory Usage
> http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
>
> HPROF Memory Dump in YourKit:
> http://img38.imageshack.us/img38/431/memorydumpclasslist.png
>
> What's going on here?
>
> Just some info on our app. Our pages are similar to a CMS system, except that instead of static content, we serve up different components (forms, etc) for users. We use a Dispatcher and overriden LinkFactory to map seo-optimized URLs to a given Page. Many different URLs may map to the same page and the same URL may map to more than 1 page based on user's status. A given page will have multiple layouts injected into it, and each layout will have multiple components injected into it (it goes a little bit deeper than that). At runtime, a page configuration is read from the database based on the URL and user's status, and the relevant layouts and components to show are selected. Since Tapestry is limited in the way that it can only use a component that has already been injected to the page (ie. IoC can't dynamically load a component without having being referenced in the page before), each page can load a multiple different components.
>
> I can understand if this complex scenario needed a couple of hundred megs, but 2 GB? And even more worrisome, why does it not collect during garbage collection? During the whole test of 20 minutes or so, more than 6 minutes were spent in GC.
>
> Any ideas? Thoughts?
>
>
>
>
>
> ---------------------------------------------------------------------
> 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