tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: RE : Tomcat 6.0.35 Crashed again
Date Fri, 12 Apr 2013 02:02:35 GMT
On Thu, Apr 11, 2013 at 8:02 PM, Martin Gainty <mgainty@hotmail.com> wrote:

> 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.htmlMartin
>
>
Interesting. Thanks!


> ______________________________________________
> 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