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: smithh032...@gmail.com
> To: users@tomcat.apache.org
>
> On Thu, Apr 11, 2013 at 10:41 AM, Mark H. Wood <mw...@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
