|
»
»
« Return to Thread: PermGen OutOfMemory, JRuby 1.2.0
Re: PermGen OutOfMemory, JRuby 1.2.0
by Jacob Kessler
::
Rate this Message:
Chad Johnson wrote:
> On Thu, Jun 25, 2009 at 11:41 AM, Jacob Kessler<Jacob.Kessler@...> wrote:
>
>> From the GlassFish end of things, we've noticed three things that cause
>> this.
>>
>
> Excellent, thanks for sounding off on this issue Jacob!
>
>
>> The first is Grizzly caching Request objects in thread local. While that's
>> good for performance reasons, it ends up meaning that a reference to the
>> JRuby runtime will stick around until the cache is cleared. There should be
>> a fix in the next released version of GlassFish (both gem and server), and
>> in the mean time you can "manually" clear the cache by sending several
>> requests to the server after undeploy, such as to a non-existent
>> contextroot.
>>
>
> Does this "manual clear" need to occur after the un-deploy but before
> the subsequent deploy of the app?
>No. The issue is that Grizzly worker threads don't clear their caches on
undeploy, so cached data persists after undeployment until each worker
thread has processed a new request. The "manual clear" is just a way to
make each worker thread process a new request. Under normal usage, the
ratio of deployments to requests is low enough that it isn't an issue,
but in development environments where the ratio of deployments to
requests can fall to 1:1 it is.
>
>> We've also seen some issues around JRuby unregistering itself as a secure
>> communications provider (through JRuby-openssl). Similarly, that ends up
>> keeping a reference to a JRuby runtime, so that things aren't collected. I
>> know that the JRuby people are working on getting a fix together for that,
>> in the mean time the default JRuby limited openssl doesn't seem to have this
>> issue.
>>
>
> In my case I am using the "limited openssl" option so I don't think
> this one is effecting me.
>
>
>> Lastly, there is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990
>> , which likely affects all of the listed application servers. As mentioned
>> in the bug, increasing permgen size (while having class unloading enabled)
>> will cause correct behavior and no leak. I'm working with one of the JDK
>> team members to get a fix for this finally integrated into the JDK.
>>
>
> Do I need to go out of my way to enable class unloading? Is there a
> special JVM option that forces this feature to be enabled?
>Yes. By default, the HotSpot JVM doesn't bother garbage collecting the
permanent generation at all, since it's assumed that very few
classloaders will become collectible. Since each application gets its
own classloader, application servers are an obvious exception to this.
You'll want to run with the following JVM options:
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
Which will enable class unloading.
>
>> Tomcat and JBoss may have other, or additional, causes of permgen leakage. I
>> haven't looked into this using them, so I can't provide much information
>> there.
>>
>
> Thanks!
> -CJ
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
> On Thu, Jun 25, 2009 at 11:41 AM, Jacob Kessler<Jacob.Kessler@...> wrote:
>
>> From the GlassFish end of things, we've noticed three things that cause
>> this.
>>
>
> Excellent, thanks for sounding off on this issue Jacob!
>
>
>> The first is Grizzly caching Request objects in thread local. While that's
>> good for performance reasons, it ends up meaning that a reference to the
>> JRuby runtime will stick around until the cache is cleared. There should be
>> a fix in the next released version of GlassFish (both gem and server), and
>> in the mean time you can "manually" clear the cache by sending several
>> requests to the server after undeploy, such as to a non-existent
>> contextroot.
>>
>
> Does this "manual clear" need to occur after the un-deploy but before
> the subsequent deploy of the app?
>
undeploy, so cached data persists after undeployment until each worker
thread has processed a new request. The "manual clear" is just a way to
make each worker thread process a new request. Under normal usage, the
ratio of deployments to requests is low enough that it isn't an issue,
but in development environments where the ratio of deployments to
requests can fall to 1:1 it is.
>
>> We've also seen some issues around JRuby unregistering itself as a secure
>> communications provider (through JRuby-openssl). Similarly, that ends up
>> keeping a reference to a JRuby runtime, so that things aren't collected. I
>> know that the JRuby people are working on getting a fix together for that,
>> in the mean time the default JRuby limited openssl doesn't seem to have this
>> issue.
>>
>
> In my case I am using the "limited openssl" option so I don't think
> this one is effecting me.
>
>
>> Lastly, there is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990
>> , which likely affects all of the listed application servers. As mentioned
>> in the bug, increasing permgen size (while having class unloading enabled)
>> will cause correct behavior and no leak. I'm working with one of the JDK
>> team members to get a fix for this finally integrated into the JDK.
>>
>
> Do I need to go out of my way to enable class unloading? Is there a
> special JVM option that forces this feature to be enabled?
>
permanent generation at all, since it's assumed that very few
classloaders will become collectible. Since each application gets its
own classloader, application servers are an obvious exception to this.
You'll want to run with the following JVM options:
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
Which will enable class unloading.
>
>> Tomcat and JBoss may have other, or additional, causes of permgen leakage. I
>> haven't looked into this using them, so I can't provide much information
>> there.
>>
>
> Thanks!
> -CJ
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: PermGen OutOfMemory, JRuby 1.2.0
| Free embeddable forum powered by Nabble | Forum Help |
