On 30/01/2012 16:33, Luciano Andress Martini wrote: > 2012/1/30, Luciano Andress Martini <777u...@gmail.com>: >> Pid i changed the configuration, like this: >> >> JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 >> -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC >> -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" >> >> The system is 64 bits + Java 64 bits, running in debian >> paravirtualized with Xen. >> >> >> 2012/1/30, David kerber <dcker...@verizon.net>: >>> On 1/30/2012 11:05 AM, Luciano Andress Martini wrote: >>>> 2012/1/30, Caldarale, Charles R<chuck.caldar...@unisys.com>: >>>>>> From: Luciano Andress Martini [mailto:777u...@gmail.com] >>>>>> Subject: Re: Java.lang.out.of.memory not clearly.... >>>>> >>>>>> Jeffrey im sorry, but i need to ask, my boss says that is impossible >>>>>> to be a problem in the software cause java unalocate objects >>>>>> automatically, is that true? >>>>> >>>>> A) Stop your top posting - it's incredibly annoying and makes people >>>>> much >>>>> less likely to help. >>>>> >>>>> B) Your boss is wrong. Google for many examples of memory leaks in >>>>> Java. >>>>> >>>>> - Chuck >>>>> >>>>> >>>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE >>>>> PROPRIETARY >>>>> MATERIAL and is thus for use only by the intended recipient. If you >>>>> received >>>>> this in error, please contact the sender and delete the e-mail and its >>>>> attachments from all computers. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>>> >>>> >>>> Thank you and sorry Chuck. >>>> Jeffrey what is your opinion about this? >>>> The development team is using a software that "Draw" java code called >>>> developer, and do not programming in. Im a assembler/C programmer and >>>> don't have so much knowing about java. >>> >>> Java can have memory leaks just as easily as C can, but if the app is >>> standalone, it will release them when the app closes and the JRE shuts >>> down. >>> >>> I have killed tomcat more than once with memory leaks, so it's easy to >>> do. I'm not the expert that Chuck and Mark T are, but here is my >>> understanding of what happens: if the app is running under tomcat, the >>> JRE never shuts down since tomcat is using it. That means the JRE can >>> not free up memory that your app has left allocated, as it would be able >>> to in a standalone app. So your Tomcat app has to clean up after itself >>> because there is nothing else that can do so. >>> >>> >>>> >>>> But all the fault is falling back to me in the company. >>> >>> I know the feeling :-/
> Sorry the gmail is doing wrong with my messages =/ > > I changed the configuration like this: > JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 > -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC > -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" -XX:MaxPermSize=1024M still seems large. PermGen is the memory where the classes are held, not the class instances. Unless you are loading LOTS of classes you should be able to get away with much a smaller number here. The JVM probably isn't even using it as you have not specified -XX:PermSize, so it's probably on the default and is using 32Mb. The -Xmx is set at a reasonable (if odd) number. I usually use multiples of 32. You still didn't say how much physical memory you have available. This is important. p -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
