|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
|
|
Tomcat and PermGenThis is not quite a question about out of memory errors. It's a question about the behaviour of contexts when deployed and un-deployed and what should happen to the non-heap (or in fact any) memory when we undeploy a context.
From my understanding (and it's not a good one) I would expect to see a drop in PermGen memory area when we undeploy a context. Currently I'm seeing a very small increase and then a much larger (9-15mb) increase when we redeploy which is suggesting that significant parts of the context are being retained through some gc connection. Any suggestions for tracking this down? Thanks Gerwood --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Tomcat and PermGenGerwood Stewart wrote:
> This is not quite a question about out of memory errors. It's a question about the behaviour of contexts when deployed and un-deployed and what should happen to the non-heap (or in fact any) memory when we undeploy a context. > > From my understanding (and it's not a good one) I would expect to see a drop in PermGen memory area when we undeploy a context. Currently I'm seeing a very small increase and then a much larger (9-15mb) increase when we redeploy which is suggesting that significant parts of the context are being retained through some gc connection. > > Any suggestions for tracking this down? Your understanding is correct. For some hints: http://markmail.org/thread/ylau4txi2onthgsh Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: Tomcat and PermGenMark
Thanks for the reply. I've gone through a few things and shifted all our direct use of log4j to commons-logging (this may not be a good thing, but consistency was the point) and then put commons-logging and log4j into tomcats common/lib directory... (recommendation from a colleague) Re-running this with a profiler has shown that things appear to be cleaning up better and the heap space has a much more significant garbage collection afterwards. Problem is that permgen space still appears to ONLY build up... Do you know of any ways to track down what might be 'stuck' here or a starting point I could use? If you have any info on the logging issue it would be helpful but from my Google searches everyone seems to have a differing (if only slightly) view on this. Thanks Gerwood ________________________________________ From: Mark Thomas [markt@...] Sent: Tuesday, 3 November 2009 11:04 AM To: Tomcat Users List Subject: Re: Tomcat and PermGen Gerwood Stewart wrote: > This is not quite a question about out of memory errors. It's a question about the behaviour of contexts when deployed and un-deployed and what should happen to the non-heap (or in fact any) memory when we undeploy a context. > > From my understanding (and it's not a good one) I would expect to see a drop in PermGen memory area when we undeploy a context. Currently I'm seeing a very small increase and then a much larger (9-15mb) increase when we redeploy which is suggesting that significant parts of the context are being retained through some gc connection. > > Any suggestions for tracking this down? Your understanding is correct. For some hints: http://markmail.org/thread/ylau4txi2onthgsh Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
RE: Tomcat and PermGen> From: Gerwood Stewart [mailto:gstewar8@...]
> Subject: RE: Tomcat and PermGen > > Do you know of any ways to track down what might be 'stuck' here or a > starting point I could use? Take a look at this, although the thread you read probably covered much of it: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 You're most likely going to have to slog through heap profiler output looking for objects (including java.lang.Class instances) that belong to the stopped webapp. They'll show up more readily if you just undeploy, not redeploy. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@... |
|
|
Re: Tomcat and PermGenThanks for this link. Reading that page made me a little pessimistic.
E On Mon, Nov 2, 2009 at 9:38 PM, Caldarale, Charles R < Chuck.Caldarale@...> wrote: > > From: Gerwood Stewart [mailto:gstewar8@...] > > Subject: RE: Tomcat and PermGen > > > > Do you know of any ways to track down what might be 'stuck' here or a > > starting point I could use? > > Take a look at this, although the thread you read probably covered much of > it: > > http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 > > You're most likely going to have to slog through heap profiler output > looking for objects (including java.lang.Class instances) that belong to the > stopped webapp. They'll show up more readily if you just undeploy, not > redeploy. > > - Chuck > |
| Free embeddable forum powered by Nabble | Forum Help |