Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of smithh032772@gmail.com
 designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU172-W18F179BE92BF2B125D15AEAEC10@phx.gbl>
References: 
 <CAGV1rDKZyGcbqS4i4iJ+REUe5jvzsMjrmDzLYuN1VCEJ1THL=w@mail.gmail.com>
	<BLU172-W18F179BE92BF2B125D15AEAEC10@phx.gbl>
Date: Thu, 11 Apr 2013 22:02:35 -0400
Message-ID: 
 <CAGV1rDKL9zWn8kAByOBNnGZbP-OYxEvkqQ6tKjy6LjosSThUdw@mail.gmail.com>
Subject: Re: RE : Tomcat 6.0.35 Crashed again
From: "Howard W. Smith, Jr." <smithh032772@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=001a11c3560c0601d604da204ca1

--001a11c3560c0601d604da204ca1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.htmlMa=
rtin
>
>
Interesting. Thanks!


> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de d=E9ni et de confidentialit=
=E9
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugt=
e
> 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 =EAtre privil=E9gi=E9. Si vous n'=EAt=
es pas le
> destinataire pr=E9vu, nous te demandons avec bont=E9 que pour satisfaire
> informez l'exp=E9diteur. N'importe quelle diffusion non autoris=E9e ou la=
 copie
> de ceci est interdite. Ce message sert =E0 l'information seulement et n'a=
ura
> pas n'importe quel effet l=E9galement obligatoire. =C9tant donn=E9 que le=
s email
> peuvent facilement =EAtre sujets =E0 la manipulation, nous ne pouvons acc=
epter
> aucune responsabilit=E9 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=3DD:\apache-tomee-plus-1.6.0-SNAPSHOT\temp
> > -XX:+HeapDumpOnOutOfMemoryError
> > -Djava.awt.headless=3Dtrue
> > -Dcom.sun.management.jmxremote.port=3D422
> > -Dcom.sun.management.jmxremote.ssl=3Dfalse
> > -Dcom.sun.management.jmxremote.authenticate=3Dfalse
> > -Xms1024m
> > -Xmx1024m
> > -XX:MaxPermSize=3D384m
> > -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=3D1024m
> > just to see if I ever get an OOME; so far, so good (never experienced a=
n
> > OOME), but recently, I did experience some unexpected/unwanted behavior
> > with one of my @Schedule processes which was attempting to sync some da=
ta
> > 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 'he=
ap
> > dump' instead of a 'stop' tomee/tomcat. Everyday, I listen and read the=
se
> > questions/responses on tomcat list, and I can't believe that I forgot t=
o
> do
> > a 'heap dump'. :(
> >
> > Also, please note that I occasionally stop-deploy-and-start tomee/tomca=
t
> > 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 i=
s
> > 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
>
>

--001a11c3560c0601d604da204ca1--