|
»
»
« Return to Thread: PermGen OutOfMemory, JRuby 1.2.0
Re: PermGen OutOfMemory, JRuby 1.2.0
by Lenny Marks
::
Rate this Message:
Haven't read this thread carefully, but in case it helps.. We've
always had memory leak problems related to redeploying apps in Tomcat.
I once tracked it down to the problem with class loaders not being
garbage collected(I think related to statics). Its never been a
problem for us in production since we never hot deploy apps there, but
its always been a PITA for continuous integration.
See:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
also "Web application reloading and static fields in shared libraries"
in the Tomcat release notes http://tomcat.apache.org/tomcat-6.0-doc/RELEASE-NOTES.txt
I could easily see how these issues apply to other app servers.
-lenny
On Jul 29, 2009, at 10:41 AM, Chad Johnson wrote:
> On Thu, Jun 25, 2009 at 2:52 PM, Jacob
> Kessler<Jacob.Kessler@...> wrote:
>> 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.
>
> For the record, here's the JVM option recipe that I ended up using :
>
> -XX:MaxTenuringThreshold=15
> -XX:MaxNewSize=512m
> -XX:NewSize=512m
> -Xverify:none
> -XX:+UseConcMarkSweepGC
> -XX:ParallelGCThreads=4
> -XX:+UseParNewGC
> -XX:+CMSClassUnloadingEnabled
> -Xmx2100m
> -Xms2100m
> -Xss1m
> -XX:MaxPermSize=512m
> -server
> -XX:NewRatio=1
>
> After implementing these set of options and giving Grizzly a chance to
> release it's held resources I am still seeing runtimes held onto after
> a reload.
>
> -Chad J
>
> ---------------------------------------------------------------------
> 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
always had memory leak problems related to redeploying apps in Tomcat.
I once tracked it down to the problem with class loaders not being
garbage collected(I think related to statics). Its never been a
problem for us in production since we never hot deploy apps there, but
its always been a PITA for continuous integration.
See:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
also "Web application reloading and static fields in shared libraries"
in the Tomcat release notes http://tomcat.apache.org/tomcat-6.0-doc/RELEASE-NOTES.txt
I could easily see how these issues apply to other app servers.
-lenny
On Jul 29, 2009, at 10:41 AM, Chad Johnson wrote:
> On Thu, Jun 25, 2009 at 2:52 PM, Jacob
> Kessler<Jacob.Kessler@...> wrote:
>> 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.
>
> For the record, here's the JVM option recipe that I ended up using :
>
> -XX:MaxTenuringThreshold=15
> -XX:MaxNewSize=512m
> -XX:NewSize=512m
> -Xverify:none
> -XX:+UseConcMarkSweepGC
> -XX:ParallelGCThreads=4
> -XX:+UseParNewGC
> -XX:+CMSClassUnloadingEnabled
> -Xmx2100m
> -Xms2100m
> -Xss1m
> -XX:MaxPermSize=512m
> -server
> -XX:NewRatio=1
>
> After implementing these set of options and giving Grizzly a chance to
> release it's held resources I am still seeing runtimes held onto after
> a reload.
>
> -Chad J
>
> ---------------------------------------------------------------------
> 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 |
