Hi Mik,
as i'm not an expert about jrails, so i might be totaly wrong,
but add to your app -XX:+PrintGCDetails, this way You will be able to
see what's going on in real time.
Also if Your app works ok without adding heap space it means it's not leaking.
GC in java is a very wide subject, what i can recomend is reading more about it,
and upgrading jruby because it's all the time tuned to eat less and less memory.
Also there are more specific switches to control every generation.
I had a problem where adding more heap space caused adding more space
for new generation,
and in effect was throwing an exception.
Hope that helps,
Paweł Wielgus.
2009/6/19 Michael Gannon <
michael.gannon@...>:
> Hi List,
>
> We have been pushing our application with some performance testing of late
> and during these tests we are experiencing some PermGen out-of-memory
> problems using JRuby 1.2.0 + Rails 2.2.2. Our application is a multithreaded
> app, a main thread with a number of worker threads. The worker threads are
> fairly simple really, mainly making use of ActiveRecord libraries, then we
> simply let them die.
>
> For our testing we have increased the heap size and only now are we
> encountering a PermGen problem. I have read the article by Nick Sieger
> (
http://blog.nicksieger.com/articles/2008/02/21/jruby-and-the-permanent-generation)
> but what isn't clear is how to estimate the required PermGen size, when is
> enough enough? Is there a reason why we are only encountering the problem
> after increasing the heap size?
>
> We as yet have not changed the default PermGen sizes so they are as default
> (64m max?) as we want to understand what is going on before we start
> increasing things across the board.
>
> I guess my question boils down to a few things:
> 1/ Do we have a problem? A leak? What is a good stratery for detecting
> this leak? Or is it a known problem solved with a larger PermGen space?
> 2/ If more PermGen space is the answer how can we estimate the
> requirements?
>
> Any info would be great,
>
> Cheers,
> Mik.
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email