On Thu, Apr 11, 2013 at 8:02 PM, Martin Gainty <mgai...@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: 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 > >
