tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: RE : Tomcat 6.0.35 Crashed again
Date Fri, 12 Apr 2013 00:02:48 GMT
you need to do take a look at the loaded JSF webapps and find outwho is acquiring  a resource
and not closing the resource
who is acquiring large amounts of heap and not releasingbe aware any reference to an any object
in another class gives the class the right to be placed into PermGenHibernate with cglib proxies
are notorious memory hogs awatch your PermGen get pegged when Hibernate and cglib proxies
are loadedStatics are another  set of culprits of of heap usage 
Remember all long lived heap objects are eventually placed into Permgen Find the tools to
track eden heap, tenured heap and PermGen 
http://www.integratingstuff.com/2011/07/24/understanding-and-avoiding-the-java-permgen-space-error/
get familiar with taking heap dumps with jmap and analyzing with jhathttp://javarevisited.blogspot.com/2011/05/java-heap-space-memory-size-jvm.html
Martin 

______________________________________________ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten
wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist
unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet
keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen
wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire
prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe
quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information
seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les
email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune
responsabilité pour le contenu fourni.

 > Date: Thu, 11 Apr 2013 11:40:46 -0400
> Subject: Re: RE : Tomcat 6.0.35 Crashed again
> From: smithh032772@gmail.com
> To: users@tomcat.apache.org
> 
> On Thu, Apr 11, 2013 at 10:41 AM, Mark H. Wood <mwood@iupui.edu> wrote:
> 
> > Really, no one else can tell you what settings to use.  The best we
> > can hope for is some accepted rules of thumb *as starting points* for
> > further tuning.
> >
> >
> +1 to Dan, Neven, and Mark's responses. Please consider-or-do 'everything'
> that they mentioned/recommended.
> 
> I did want to share my java settings for my
> currently-considered-a-low-scale JSF web app running on Windows Server 2008
> R2 64bit server with 32GB RAM.
> 
> -XX:HeapDumpPath=D:\apache-tomee-plus-1.6.0-SNAPSHOT\temp
> -XX:+HeapDumpOnOutOfMemoryError
> -Djava.awt.headless=true
> -Dcom.sun.management.jmxremote.port=422
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=false
> -Xms1024m
> -Xmx1024m
> -XX:MaxPermSize=384m
> -XX:+UseTLAB
> -XX:+UseConcMarkSweepGC
> -XX:+CMSClassUnloadingEnabled
> 
> I am very pleased with the GC performance of my app, and I do like to
> monitor the performance of the app via JMX remote connection via Java
> Visual VM. My app runs between 200m to 500m, but I am keeping Xms/Xmx=1024m
> just to see if I ever get an OOME; so far, so good (never experienced an
> OOME), but recently, I did experience some unexpected/unwanted behavior
> with one of my @Schedule processes which was attempting to sync some data
> from database to/with Google Calendar, and google Calendar service returned
> google calendar error 503, and I recognized that the memory got up to 500m,
> and the google calendar error 503 did not resolve itself over an hour
> (@Schedule executes every 2 to 4 minutes, if error occurs, then data is
> appended to the queue for later retry attempt). I never seen that behavior
> and I don't know if I will see it again; i wish I would have done a 'heap
> dump' instead of a 'stop' tomee/tomcat. Everyday, I listen and read these
> questions/responses on tomcat list, and I can't believe that I forgot to do
> a 'heap dump'. :(
> 
> Also, please note that I occasionally stop-deploy-and-start tomee/tomcat
> almost-on-a-daily-basis to deploy new app-or-configuration-or-library
> updates; also, the app or tomee (or tomcat) seem to accumlate threadlocals
> over time, and if uptime is > 1 day, then I 'think' I see that memory is
> not released, and I think eventually as uptime increases, then the
> app/tomee/tomcat will result in OOME. :)
> 
> At any rate, hope this helps.
> 
> Howard
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message